I want to discuss today an important point that is overlooked (or not given its due attention) in most architecture initiatives. It is a “current state architecture”. It is not uncommon that some architects jump on to developing target architecture with its associated implementation roadmap based on some requirements without current state architecture. Such architects may question the value of current state architecture because developing current state architecture may take time and incur additional cost (especially for large organizations). So, what exactly is the value of current state architecture?
The answer is simple. Assume you have stomach pain. The pain is so strong that you could not perform your daily work and you decide to go see your doctor. Your doctor asks you – what is the problem? You tell him you feel sever pain in the stomach. Now, the “target” for you and the doctor is to “feel better or relief the pain so that you get back to your normal routine”. How you get to that “target” is what matters now. If your doctor is like those architects who don’t see the value of “current state”, he will subscribe you a medication and tells you to go try that. Assume he is like that. You went off and spent your time and money – but your pain is even getting worse. You then decided to call 911 which took you to the emergency hospital. The doctor at the hospital asks you the same question – what is the problem? You tell him your problem. This doctor now tries to understand your current situation through series of examinations – blood, stool, temperature, pressure, etc… The doctor then comes back to tell you your exact current situation (current state) and tells you the steps (roadmap) he is going to take to treat the illness so that you will be well again (target state). You get the right medication only after your current situation is understood and you are not going to spend your money and harm yourself trying many different medications hoping that one of them will hit the target. It is not hard to see the value of the current state architecture. Its value is much greater than the associated cost and time of developing the current state architecture.
There are two possible outcomes when one attempts to do target architecture and roadmap without current state architecture.
TOGAF clearly defines the need for current state architecture – it uses the term “Baseline Architecture”. Understanding current state helps in understanding the current stakeholders concerns. Without such basic understanding, the architecture is done in a vacuum without real base.
If current state architecture has such an importance, then the next question to ask is – how much of the current state need to be done? To answer this question, it is helpful to know the scope and objectives of the architecture initiative. Any architecture initiative needs to define clear scope and objectives. Based on the scope and objectives, the current state architecture is done to the level that is enough to highlight the current issues/challenges/needs to propose target state to the stakeholders. You will clearly know what components are to be retired or replaced or changed. In addition to that you will also identify building blocks or components that are reusable in the target state architecture. By understanding stakeholders concerns by focusing on the relevant current state areas, you will be well equipped to address the various concerns in the target architecture. This makes it easy for the stakeholder to be satisfied with your vision and bless (approve) your target architecture. Your roadmap will also be realistic and expectation is properly managed.
Bye for now -:)
Awel Dico
Because of my involvement in SOA/TOGAF practical guide project at The Open Group, I am getting many questions related to the use of EA frameworks in general. I just want to share some of my discussions with people on this topic here. Many enterprises have been (and are being) challenged, for example, on use of TOGAF for their real EA initiatives. The challenge is the misconception that EA framework, such as TOGAF, can be used “as is” for supporting Enterprise Architecture work. EA frameworks are “frameworks” and they are not meant to directly apply to all situations and solve all enterprise architecture challenges the same way. This means such EA frameworks must be viewed as a “guide” and needs to be customized to address the individual enterprise needs. EA framework, such as TOGAF, needs to be customized by taking into account at least two factors:
In addition to the above points, one should also pay attention to the link between EA deliverables and the actual solution implementation projects. Whatever you do in EA, its value is realized only when the artefacts are deployed and show value to business (e.g. customer satisfaction, business agility, etc). The EA metrics (to measure the success of EA effort) are collected based on such values to the business. EA deliverables must guide and support the solution implementation projects. Thus, EA framework customization should include such a linkage to the solution implementation projects.
In part 2 of my blog entry I discussed the five elements of end-to-end SOA work. The focus of that discussion was to introduce and define those elements I think are required for successful SOA initiatives. The diagram I show there is good for small organizations that are not divided into business domains. Large organizations or enterprises have usually more than one independently operated domain area. For such organizations that diagram need to include domain architecture as a part of enterprise architecture. In this article (part III) I want to discuss the Service Oriented Enterprise Architecture Framework (SOEAF) that can be used in large enterprises that can be divided into multiple business domains.
Below I want to share my thoughts on some details and link to the concept of architecture partitioning approach introduced in TOGAF 9. I gave an overview of the three architecture levels introduced in TOGAF 9 earlier. The three architecture levels are: Strategic Architecture, Segment (or Domain) Architecture and Capability Architecture. I think there is no misinterpretation of what the first two architecture level types are. The third level (i.e. Capability Architecture) has generated some interesting discussions. For some it could be defined as the architecture activity where capabilities are identified and their dependencies are defined to address the domain business goals. For others it could be interpreted as a commonly know type of solution architecture. I am not going to conclude one is wrong and the other is correct. Regardless of the different interpretations of what it can be, for the purpose of this discussion I interpret the capability architecture as the following: - the architecture that is done to identify lower level business and IT capabilities within a domain (or segment) in order to optimally support the higher level business capabilities identified in strategic business architecture.
The assumption here is that an enterprise can be grouped into two or more domains/segments and that each domain/segment has one or more capabilities identified and defined to address the domain/segment goals while supporting the enterprise business strategy. All the domain (or segment) architectures together they make up enterprise architecture. The strategic architecture provides direction and guidance to the various domain architectures so that all the domain architecture deliverables can be viewed as a part of the whole enterprise architecture. However, not all domain/segment delivered capabilities are reusable across the enterprise – some may be just domain specific capabilities (or services) while contributing to the over all enterprise business objectives. Some business and IT capabilities can be common across the various domains and as such they can be positioned for reuse at the enterprise level.
Service Oriented Enterprise Architecture Framework (SOEAF)
The diagram above shows the complete picture of Service Oriented Enterprise Architecture Framework (SOEAF). SOEAF is the customizable enterprise framework that is based on TOGAF and SOA approach. SOEAF includes four levels of architecture as shown in the diagram. These are Strategic, Domain, Capability and Solution architectures. These architecture levels are NOT disconnected; rather they are connected from top strategic architecture down to solution architecture – the top architectures giving guidance to the lower level architectures to support the enterprise business strategy. This does not mean that the architectures cannot be done independently. It becomes more specific and concrete as one goes from strategic architecture down to solution architecture after which the implementation is done. In the diagram I only showed details of strategic architecture and solution architecture. Similar details can be shown for Domain and Capability architectures.
The other key component of SOEAF is the SOA Governance and Change management part. This uses the principles, guidelines, standards, and reference models to perform compliance assessment of the various architecture and implementation artifacts. The principles, standards and guidelines are developed at the strategic enterprise level in support of Enterprise Architecture objectives which in turn supports the enterprise business strategy. Thus, the compliance assessment of the deliverables helps the ongoing subsequent incremental deliverables to be aligned with EA objectives and reduce (or remove) unexpected cost and business risks. In addition governance activity encourages reuse and facilitates reuse by providing the necessary enterprise and domain level processes and tools. Some of the key tools of governance are the Enterprise Architecture Repository and SOA Service Registry tools. The various architecture artifacts can be published in an architecture repository based on some enterprise acceptable taxonomy. In addition, the SOA services (both business and technical services) should be published in SOA Service Registry tool to facilitate service reuse. In general, reuse is not as easy as saying it. It is one of the hardest things to achieve even with governance in place. However, I think proper governance processes and tools coupled with skilled resource can help achieve reuse of both architecture and services over time. Architecture reuse is different from SOA service reuse; but they aim for one goal – reduce the cost and time to implementing business capabilities and improve “time to value” of initiatives. If proper SOA governance body, equipped with the necessary tools and processes, is not established the enterprise SOA initiative may not deliver any value to the business as expected.
SOEAF also includes end-to-end security architecture which addresses authentication and access control to deployed business services, intrusion detection, privacy, logging and auditing. I think security should be externalized from SOA based business service implementations. Authentication and authorization to business services can be handled external to the services that are being protected – i.e. services should not be aware of those security functions. The only time the incoming security information is needed by business services is when the business service has to pass some user security context to downstream legacy applications. This is because those legacy applications may expect user information (including password) in the message body. Even then I think there are ways to add those required information to the outgoing message with no intervention from business service implementation if proper SOA infrastructure (e.g. Enterprise Service Bus) is deployed.
For SOEAF to be complete, it must be supported by the following:
Finally, SOEAF must include metrics for measuring the value of Enterprise Architecture to the business. As the various architectures are done by the various teams using SOEAF, some key metrics need to be collected at some key governance points. Example of such a metrics is the collection of service reuse, number of exceptions granted, infrastructure reuse, etc.
It is not possible to give a complete detail about SOEAF in one article. Please let me know if you think this type of framework is useful and let me know the part you want me to discuss in some detail here. Thanks for reading – I hope you have enjoyed your stay.
Awel Dico, PhD
I discussed earlier that SOA and EA should not be seen as separate and competing initiatives. In this post I would like to share my thoughts on the characteristics of a successful SOA initiative. I will first discuss a very useful concept introduced in TOGAF 9. Previously I only discussed an overview of TOGAF 9 here without much detail. TOGAF 9 introduced a way of dealing with EA through architecture partitioning. There are three architecture types defined, namely, Strategic Architecture, Segment (or Domain) Architecture and Capability Architecture. The relationship between these three architecture types is depicted on the following diagram (taken from TOGAF 9 document).
Source: The Open Group (TOGAF 9 - Architecture levels)
As a member of the Open Group SOA working group, I have been working on SOA-TOGAF practical guide project as a co-chair. The objective of the project is to produce a practical guide that enterprise architects would use to deliver SOA using TOGAF. Well – you got the feeling… how hard this work is. One needs to understand SOA and TOGAF not only from theoretical perspective, but also practical aspect of it. For the success of this project, the understanding of both SOA and TOGAF is critical. The scope of this project is not to merge TOGAF and SOA and rewrite TOGAF. The guide will help the enterprise architects to understand and make the necessary adjustments to TOGAF in such a way that TOGAF can be used for SOA initiatives. The team is working hard on this project and lots of interesting discussions are going on. All the discussions I had on this subject make me think of the importance of bringing SOA and TOGAF together. What this means is that, given the acceptance of SOA in industry, SOA must really get integrated into EA through major enhancement of EA frameworks and methodologies. Particularly, the best of TOGAF and the best of SOA practices should come together to create one common enterprise architecture framework. I refer to this new framework as Service Oriented Enterprise Architecture Framework (SOEAF). I will describe this in some detail soon.
Some Clarification update below:
I just want to clarify what I meant by brining SOA and TOGAF together. This doesn’t mean changing TOGAF to accommodate SOA. TOGAF is very good as it is a generic architecture framework that supports various architectural styles. SOA is just one architectural style. What I meant by brining the two together is applicable to organizations adopting both TOGAF and SOA. Those organizations benefit most if they can bring the strength of the two (SOA and TOGAF) to a common architectural framework – which I referred to as SOEAF.
After you have done your pre-work (i.e. made a business case and decided to invest in SOA), where do you start and how do you organize your work to move forward? That is where most of the time is spent with current SOA pursuers. So, how can you get started?
Any SOA initiative need to first understand and prepare to work simultaneously in three major fronts. These are:
From the surface, this seems simple and may be overlooked leading to unexpected cost and disappointments. Such a mistake arises when you fail to understand the requirements for all of these tasks; and rather think implementing SOA is simply wrapping functions with Web Services interfaces. A successful SOA implementation realizes these three major fronts and progress about implementing them incrementally to meet current and evolving business needs.
Properly implemented SOA allows business to respond quickly and efficiently to changes in business requirements, i.e. business agility. This gives the business the ability to leverage change for competitive advantage. Achieving this requires some discipline and changes in current IT approach to business application development. Currently, business and IT groups within one organization communicate in a vague way and disconnected when it comes to understanding business dynamics. Business requirements do not flow smoothly and unaltered from business to technology implementations. As a consequence changing the current systems (applications) to support changes in business needs (or to accommodate new requirements) is too costly, if not impossible.
SOA approach requires three inter-related elements, namely, business requirement, service and technology – to work together. Understanding the relationship between these three elements is crucial for achieving business agility. That is, business requirements must drive the services and the services drive technology. Services address the needs of the business and technology provides a means for implementing and deploying those services.
The other part is enterprise wide governance process to ensure that SOA principles are met through compliance with enterprise guidelines, standards and polices. Establishing good governance process is a key to maximize the benefits and reduce risks while the enterprise incrementally moves to full SOA based implementations.
This SOA approach is in agreement with the TOGAF framework . The three elements introduced above maps to the first three architectures in TOGAF framework; namely, business architecture, Information architecture and technology architecture. Business architecture deals with business requirements and business processes. Information architecture addresses the design of services and data; while Technology architecture addresses the infrastructure for services development and deployment. If you are familiar with TOGAF framework, Information architecture consists of Data and Application architectures. There is no disagreement if you understand that, in SOA approach, applications are group of services and data is what those service manipulate.
Going back to the three major fronts for SOA implementation introduced above, the following can be summarized: