Why do we need RA s?
As part of the Time-to-Value Initiative, Reference Architectures have been identified as an emerging theme: Common customer deployment & usage patterns to facilitate earlier initial customer value. These patterns go well beyond individual products; actually deployment patterns for individual products have been documented for many products already. What was missing was a reference architecture for the entire domain such as Availability and Performance management.
But documentation of these patterns is not enough. We also wanted these templates to be validated so that they can become the recommended patterns for our customers. The templates become our architectural best practices.
Making these patterns more and more pervasive has benefits for both, our customers and IBM. Customers get quicker to value quicker. The overall solution gains in quality due to repeated patterns. It allows Development to perform targeted enhancements based on these patterns and avoids one-off enhancements. Driving consistency further allows the support organization to be quicker in resolving issues.
Let me share a story to explain: When I am called into troubled projects, I always compare the specific project / implementation with those that I knew were working at other accounts. By identifying the differences between these two implementations gave me a good way to perform targeted analysis to find the root-cause.
What RA s exist today ?
The following Tivoli Reference Architectures have been defined:
- Business Service Management (BSM)
- Enterprise Asset Management (EAM)
- Service Delivery and Process Automation (SDPA)
- Cloud Computing (CC)
- Communication Service Provider (CSP)
- Security Management
In addition, we are working on a RA for Storage Management
What does an RA contain ?
The Reference Architectures are a set of work products
(think “chapters”) that describe a specific aspect of the architecture. These
work products are based on the IBM architecture methodology called GSMethod and Unified Method Framework (UMF). See this developerWorks article for an introduction to the IBM Views and Viewpoints Framework for IT systems
The first set of work products give a description of the management environment:
- Current IT Environment
- Business Driver
- Customer Wants and Needs
The “Business Drivers” work product identifies the top business issues, challenges or priorities for the enterprise. They can be thought of as high-level immutable requirements, which the strategy and its infrastructure (business and IT) must support.
Customer Wants and Needs form the functional value an offering provides to customers. They are requirements/desires, from the perspective of the customer, that define minimum expectations and/or ideal value at each interactionbetween the client’s customers and the client's business products, services and/or processes.
You may wonder why there is a chapter on “business drivers” and one on “wants and needs”. Each of us has probably faced the situation where a lot of requirements were raised in the initial architecture workshop, but no one could exactly map these requirements to business drivers. The linkage of these two work products allow us to identify these gaps and prioritise requirements in the context of the business.
The second set of work products provide the functional and non-functional requirements of the solution:
- Non Functional Requirements
- Use Cases
The Non-Functional Requirements for a business system address those aspects of the system that, whilst not directly affecting the functionality of the system as seen by the users, can have a profound effect on how that business system is accepted by both the users and the people responsible for supporting that system. Examples are Performance, Scalability and Availability. The Use Case Model work product describes the functional requirements of the system under development. First we define the individual personas (“Actors”) and than flows how these users are expected to interact with the solution.
Next, the fun part starts, something we call “architectural thinking” in IBM. With all the inputs on environment, needs and requirements documented in the above work products, we now develop an architecture based on capabilities, and integrated into a comprehensive solution:
- Architecture Overview
- System Context Document
- Architectural Decisions
- Component Model
- Deployment Units
- Configuration Parameters
- Operational Model
The Architecture Overview Diagram work product is a schematic diagram that represents the governing ideas and candidate building blocks of IT system or enterprise architecture. It provides an overview of the main conceptual elements and relationships in the architecture.
Don’t underestimate the value of an AOD: How many times have you asked to pitch a project to someone? Wouldn’t it be nice to have a chart that conveys this message graphically? In my projects, I make a habit that every project member has a chart of the AOD, they are on the wall of a project room, etc. Project team members don’t work in isolation, they need to know the context - what the big picture is that he is contributing to.
While we shape the architecture, the new solution doesn’t live in isolation. It needs to interface with existing solutions. The best example is probably an LDAP, that the new solution will use for authentication and authorization. This context is documented in the System Context document.
Next, the Component Model describes the entire hierarchy of components in terms of to their responsibilities, their interfaces, their (static) relationships, and the way they collaborate to deliver required functionality. We typically decompose the individual products in component (example in ITM: Hub’TEMS, Remote’TEMS, TEPS, Agents, Warehouse Proxy, etc). The Deployment Unit work product describes components that are grouped together for deployment purposes (i.e., they execute, get stored, or are installed together on a node).
A key work product is the Architectural Decisions. It documents important decisions about any aspect of the architecture including the structure of the system, the provision and allocation of function, the contextual fitness of the system and adherence to standards.
An architecture is understood partly through the record of the important decisions made during its development. A well-documented architecture includes its own justification and evaluation criteria. The justification and evaluation criteria may be recorded alongside the decision or, at least in part, by reference to more generally applicable principles, policies and guidelines, which are found in other work products or in external references.
Configuration Parameters describes the selection and setting of values and options that customize a package or packages. The customisation rules and standards for configuration parameters are key elements that should be well known, agreed, and documented with the client so that the package can be can be correctly configured with the appropriate settings to support the client’s intended business processes and organization.
Finally, the Operational Model work product is a representation of a network of computer systems, their associated peripherals and the systems software, middleware, and application software that they run.
This was the first entry in this blog. Looking back a bit longer than initially expected. I hope I gave you an idea on the motivation for having reference architectures in Tivoli and also insight into the actual content. Over the next several blog posts we will be introducing you to the individual Reference Architectures.
In the mean time, I do want to encourage you to participate in this blog. Share your thoughts, raise question and concerns, do comment on blog entries. We created the blog for that very purpose: Interaction between the technical leads of the reference architectures and our stakeholder, you !