Enterprise Architecture as a practice has been around for some time now. Many companies have reached a level of sophistication and maturity within their EA practices. They are well established with EA policies and governance institutionalized throughout the company.
Most EA practices were founded and matured during a period where the predominant approach to business applications was monolithic and stovepipe. Monolithic meaning encapsulating all the functionality from the data to the presentation layer including supporting capabilities like security and personalization as embedded, tightly coupled components of the application. Stovepipe in terms of providing a limited set of capabilities that may cover a function holistically but not an end-to-end process from a consumer perspective. Most of the tools used by the Enterprise Architects were founded and matured during this era as well. Because of this they are inherently structured as a reflection of the traditional environment and the traditional approach to business application development.
The concept of Service Oriented Architecture along with the associated SOA technology advancements have started the process of breaking down the monolithic and stovepipe barriers of traditional applications. Enterprise Architects have been at the forefront of driving the development of SOA solutions rather than business applications.
Initially this effort focused around Integration services and were for the most part technically driven and fostered. Today, advanced EA groups are facilitating a business driven model with the focus on layers above the integration layer providing agility through the business service layer, the business process layer and multiple distribution channels.
The problem is that traditional EA frameworks and methodologies do not represent or reflect this new model of business and IT interaction. The metadata within these repositories is not designed to foster communication between IT and the business and facilitate business agility and opportunity assessments. Service repositories have attempted to fill this gap but their lack of structure, integration and management capabilities beyond service definitions is lacking. Services are a critical part of the SOA “Stack” but they are just one part.
This problem is compounded by the fact that the structure and process used by the business to define, rank, prioritize and fund their initiatives is also a reflection of the traditional system development approach.
An effective SOA framework and management tool must formally consider and manage all the SOA assets within the stack and do so holistically. This means that metadata that relates constituents to the channels provided to them for interaction and what is being provided through those channels must be easily accessible and referenced when discussing current state with the business. Metadata showing what channels are used for some constituents but not others, processes or services provided through one channel but not another or to one constituent but not others needs to be accessible and referenced when discussing business opportunities with the business.
To a further degree an effective framework needs to identify this information in the context of its “state”. By state I mean where the capability lies on the spectrum from :
- Identified as a strategic objective
- Identified on a business units plans
- Scoped and funded
- Designed and approved
- And finally implemented
In other words, Architects need a new framework and metadata model to support the SOA asset portfolio as it grows and evolves. Architects need to respond rapidly to the business and be capable of relaying exactly where their SOA capabilities are, how they are evolving and where the opportunities lay.
They also need a new methodology for capturing business needs that map to the SOA model and the relationships from strategy to plan to project and leverage this mapping through the ongoing portfolio management process.
Following is a diagram of the Service Oriented Architecture Enterprise Architecture Framework or SOA~EAF for short. It is the result of years of attempting to run an EA practice driven by a “service based” philosophy and approach. It was initially created before the term SOA was coined but was based on the same philosophies as SOA. I’ve evolved and improved it as SOA has evolved and matured.
The remainder of this article provides an overall description of the framework and its use. If you would like a more detailed description of the framework along with…
- The overall methodology for applying it
- The SDLC and Governance processes to exercise it
- Detailed descriptions and definitions of the roles and responsibilities involved with it
…please read my book “Achieving Service Oriented Architecture – Applying an Enterprise Architecture Approach” (Wiley Company 2010).
 |
The columns represent the trace-ability of each layer from the strategy to the implementation of the business capabilities needed to achieve the strategy. The rows represent the layers of the architecture and the traceability from the consuming constituent down to the legacy application and platform supporting the capability.
The Corporate Goal/Strategy column defines the high level, longer term “Vision” of how the business sees its relationship with its constituents.
The business unit plan column lays out how each business unit plans to support the strategy over the next n periods specifying how their unit will deliver the specific capabilities they provide in each layer.
The Business Architecture column is where all the individual business unit plans are consolidated to provide a holistic front to back view of the enterprise business capabilities and the priorities for delivering those capabilities. Specific initiatives are then extracted from the compiled business plans, funded and added to the portfolio plan which is the mechanism for managing the IT deliverables.
The Reference Architecture column provides the architecture frameworks, design patterns and standards for designing and building the solution for the initiatives.
The Platform Architecture column represents the metadata associated with the physical implementation of the solution.
The intent of the framework is not to be the repository for all the documentation and artifacts associated with the planned and implemented portfolio. Business requirements are still stored in business requirement documents. The detailed design specifications and the source code are stored in their traditional mechanisms as well.
What is captured is the metadata associated with the description of the components within each cell and the relational links to their counterparts in the cells to the left and right as well as above and below.
Each component description should contain links to the location of the supporting detail documentation. For example, the definition of a business process identified within an initiative in the Business Architecture column would have a link to the location of the BPMN diagram created during the requirements gathering phase of the initiative. The Reference Architecture Column description would have a link to the BPEL process model providing the system definition of the business process. The Physical Architecture column description would include the URI for the process and a link to the physical topology diagram showing the server or cluster names and the surrounding network topology.
The horizontal relational path captured within the framework provides traceability from the BPMN to the BPEL to the URI to the physical server or cluster name where the process runs. This last piece is more critical when the BPEL technology utilizes a distributed deployment architecture.
The vertical relational path traces the upward consumption of the process through one or more specified channels to one or more specified constituents as well as the downward identification of the business services consumed in the process activities, the integration mechanisms those services use, the legacy applications data or function and the platform where that application runs.
Note: Business Services can be consumed through a process or directly through a channel. Business services consumed directly through a channel should reflect this relationship in the framework. Since Business services can be consumed for multiple reasons they may reflect relationships with multiple processes, multiple channels or both. For example, a “Get Customer Credit Limit” Service could be consumed by the “Increase Customer Credit limit” business process as well as directly by the Customer through the Customer self-service portal.
In the business architecture column these vertical relationships are “Conceptual” and defined within the cell and any linked documentation in business terms. In the Reference Architecture column these relationships are “Logical” and defined within the cell and in linked supporting documentation in terms of a defined architecture and design specification. The Physical column is a mapped physical definition of how these components interoperate in a deployed environment i.e., the physically deployed production channel invokes the URI that runs the physically deployed BPEL program that invokes the URI’s to run the deployed business services, etc.
It should be obvious by what was described above that populating the framework is a continuous process with the current state of the SOA environment reflected by the contents within. The creation of an initiative results in the creation of a high level description of the business processes and services requested by the initiative and the constituents and channels used to consume them. The initiative is created before the project is approved, funded and started. The addition of the BPMN diagram defining the business process and the link to the initiative description of the process is not added until the business requirements phase is completed and approved. The BPEL definition and the link to the BPMN is not created until design is completed. The link to the physically deployed URI is not created until the component is in production.
What may not be so obvious is that not all of the defined components described in the preceding paragraph will be new. While a new business process may be defined some or all of the business services needed by that business process may already be defined. They may be defined but only to a certain state. Some of the services needed by the process may already be in production. Some may be in design. Others may have been defined to support another initiative but have not yet started their development SDLC or approved for development.
Thus the process of defining an initiative in the framework consists of linking to existing capabilities as well as defining new capabilities. The process of creating a business initiative is performed by A Business Architect with assistance from a Solutions Architect. The Solutions Architect can quickly scope the time and cost estimates to deliver the initiative based on their knowledge of what exists, the state it is in and if it can be used as is or require additional enhancement. An example of an enhancement requirement would be the creation of a new “service stub” for an existing business service so it can be consumed through a different channel using a different protocol.
Inherent in this approach is the fact that all the initiatives from all the business units are structured the same way following the same format:
- Which constituents
- Using what channels
- Consume which Business Processes and Business Services
This creates the opportunity to look across all the initiatives for commonalities and synergies:
- Same Constituent
- Same Channel
- Same Process or service
Initiatives can now be reformatted and result in funded projects that cross business unit boundaries to provide capabilities to constituents holistically. This transforms the focus of project prioritization and funding from a business unit and (stovepipe) application perspective to a consumer driven horizontal delivery of capabilities across the business enterprise.
This also transforms the relationship and communication between the business and IT from one of “application” development or enhancement to conversations around constituents, channels, processes and services.
This is the paradigm shift of SOA and the SOA~EAF methodology and framework gives you the process and tool to institutionalize it.
Finally, the other value provided by the framework is the ability to facilitate opportunity assessments. The data captured by the framework can be used to conduct all kinds of analysis around the SOA assets and how they are used. More importantly this analysis can highlight how they are not being used and if there are opportunities to extend their use!
Below are just a few of the many questions that can be answered using the data in the framework:
- What processes and services are being used by a Constituent through one of the channels they use but not the others?
- What processes and services are being used by multiple constituents and can other constituents use them as well?
- What are all the processes and services provided through a specific channel and can they be adapted to other channels?
- How many unfunded initiatives want to deliver capabilities to the same constituent over the same channel?
- Which initiatives specify delivery of capabilities that have the highest alignment with the strategic objectives? Which of these are unfunded?
The ability to conduct this analysis quickly provides the business with information heretofore unattainable in such a comprehensive and complete manner. We all know that SOA claims to deliver business agility. This framework delivers EA agility to accelerate the business agility!
Explaining the entire framework through examples is much more than can be accomplished in an article. As I said earlier if you want to learn more you can get a more in depth explanation of the entire methodology in my book. For now I’ll focus on an example at the constituent and channel layers.
At the highest business strategy level the company should identify whom their key constituents are and how they want to interact with them. For “Customers” the strategic direction may be interaction through the Web and utilizing an IVR (you know it as the “Press 1 for…” technology) and to maintain direct customer service support as an operational but not strategic channel. The Strategy may be more granular and delineate customers based on some demographic (the web may not be a viable channel for customers in an underdeveloped country or the IVR for customer who buy your hearing impaired products.)
For “Vendors” or “Suppliers” a key strategic channel may be an EDI channel.
Each business unit puts together their plan for delivering their processes and services to the constituents through the strategic channels. Sales identifies what they want to deliver to the customer and when. Service does the same. Consolidating these business plans provides a holistic view of what is being delivered to each constituent, which channels will be used and when it is planned for delivery.
The Enterprise portfolio governance committee can evaluate this information from a top down constituent perspective and structure enterprise SOA initiatives accordingly.
Once this priority and schedule is established the alignment of any necessary legacy application enhancements to support the initiatives can be determined. The technology infrastructure and capacity plan can also be aligned to ensure that the needed technologies and capacities will be in place when needed.
This process also helps to identify disconnects between the strategy and the initiatives. If a business unit identified a need to deliver capabilities to Customers through an EDI channel this will raise a red flag since EDI was not identified as a strategic channel for Customers. Similarly, if one of the initiatives requires a major modification to a legacy application that has been identified for migration or replacement the process can trigger an analysis by Technology Governance to assess the implication and to evaluate the cost/benefit of enhancing versus accelerating the modernization/replacement.
Conclusion
The SOA~EAF methodology and framework provide a holistic, enterprise mechanism to manage and leverage an SOA asset portfolio. It provides a framework for documenting and evaluating all the business initiatives in a consistent, standardized way and the ability to tie those initiatives from their alignment with the strategy to their physical implementations. It allows the business to assess initiatives at an enterprise level and structure their delivery of solutions around constituents and channels rather than “systems”. The framework provides horizontal trace-ability from strategy to implementation and vertical trace-ability of how capabilities are consumed and leveraged. Finally, and most importantly, it provides a mechanism for Enterprise Architects to identify opportunities and expanded efficiencies that the business can evaluate and adopt.
