A pure Architectural Model (Infrastructure) isn’t sustainable if your goal is to implement true value oriented business service management solutions. One of the key things that are missing from this design pattern is the contextual information required to understand the impact any of the technology buckets has on other technology buckets, services, applications, IT or the business. We also don’t have any understanding of the role the technology buckets or their contents play in service delivery. In this design pattern, one server is just as important and “faceless” as another. We simply don’t know that when a server turns red if it’s the most critical server in the ERP application or if it’s just a backup file server.
Maturing from the Architecture Model (Infrastructure) requires a few things. First, we MUST ensure that we have a solid foundation in the basics of infrastructure management and monitoring. We must know when an infrastructure component is up, down, performing as expected or not, at capacity or over capacity, operating with a fault or error condition, etc. This is fundamental “monitoring 101” here. If it blinks green in the datacenter or somewhere in the network, branch office, or elsewhere, you need to know the fundamentals. To mature beyond this technology bucketing approach, the separation of function and purpose from the core component must happen. The application or other component installed upon a hardware/operating system platform must be equally as visible as is the hardware and operating system. If you can’t do this, you may want to think about your overall strategy, roadmap and approach towards business service management.
*soapbox*
This is something that you’ve got to define within your company and religiously ensure that your standards and expectations are followed. It continues to amaze me that most clients still struggle in this area. My guess is that better than 75% of clients I’ve worked with or heard about in the past few years don’t have a solid handle on these “monitoring 101” fundamentals across their environments. I think this is partly due to the constant change with technology but we as vendors have equal if not more blame here with our constant updates, new releases, new acquisitions, etc. This does more harm than anything as the monitoring tool group’s are scarcely staffed these days and are often seen as low in the “value chain”. Simply put, most vendors don’t make it easy for our clients to get ahead and stay ahead of the other changes in the datacenter.
*soapbox*
As mentioned in the first design patterns post, most clients are starting out with models using broad based rules that match any event by node name. They may create a technology bucket consisting of “Application Servers” and have hardware/operating system and application server events (and others) all contributing to the status of that instance. A better approach to this is to have a template for the hardware/operating system (by type, version, etc.) and a template for the application server (by type, version, etc.). The application server “depends on” the hardware/operating system and is modeled using child dependency rules or other “loose coupling” concepts. I now have immediate separation, understand the relationships and can easily create separate service models, dashboards and scorecards for the hardware/operating system group and application server group as needed (horizontal service model) in addition to the traditional (top down/bottom up service model). SLAs, reporting, root cause, right click tools and integrations are other things much easier to do with this approach.
Each template contains the SPECIFIC rules that MOST DIRECTLY indicate impact or potential impact to the hardware/operating system or application/component installed onto the hardware/operating system. This is where a direct working relationship with the hardware/operating system and application/component SME’s is most beneficial for modeling behaviors on templates. Take the time to document what instrumentation is available from the monitoring tools group and the hardware/operating system and application/component deployment/support groups. I can almost guarantee that they have their own instrumentation and monitoring tools in place. Know what events you have access to, what causes them, what clears them and what they really impact under all scenarios (normal operation, low load, high load, when dependencies (direct/indirect) have problems, etc.). Leverage the instrumentation and events that would be the ones that the SME’s recommend and get woken up in the middle of the night for. Don’t use instrumentation or events such as disk space or other utilization events UNLESS you’re sure it will impact the operation of the application or component installed on the hardware/operating system platform. Iterate and test here until you get it right. Controlling false positives and false negatives begins here!
Using separate templates may not be something you see the need for at this time. The benefits of this approach will be seen as I discuss the additional TBSM Design Patterns. Not to leave you hanging on forever, this design approach enables the greatest flexibility and openness for the future. It will enable “loosely coupled” service models and a high degree of reuse required for modeling end-to-end services and complex composite applications. It will help you to avoid “the big ugly all encompassing model” that many clients struggle with today that’s always red and provides little value. It will allow you to accurately model virtually anything within your IT and business environment in the most realistic manner possible. You should start thinking about how to develop these building blocks that will give you a much finer level of visibility and control in building end-to-end service models for business service management down the road.
Up next, Architectural Models for COTS Applications/Databases and Custom Composite Applications.
Comments on this entry are closed.