Strategic architecture is a part of the Service Oriented Enterprise Architecture Framework (SOEAF) I discussed earlier. In this post I want to share my thoughts on why Strategic Architecture is a very important part of Enterprise Architecture (EA). Many EA discussions I heard this week at The Open Group Architecture Practitioners conference in Toronto indicates that majority of current EA work lack the business architecture component and it is more focused on Information Technology aspect of an enterprise. Because of this it is extremely hard for majority of current EA team to show value to the business in a reasonable amount of time. EA must turn its focus on the Strategic Architecture if it hast to deliver value to the business. If strategic architecture is done in alignment with a business strategy, then the other down stream architectural works (Information systems architecture and technology architecture) will be driven by the business need enabling business and information technology alignment. That is why the strategic architecture is part of SOEAF. If enterprise architecture lacks the strategic aspect driven by the business strategy, then it is highly unlikely that the EA team will deliver much value to the business – rather produce the usual siloed solutions within a segment/domain of the enterprise and as a result reuse across the enterprise cannot be achieved. It is thus very important that each domain/segment architecture is driven by the strategic architecture (which by itself is driven by the business strategy).  The usual solution architectures are part of domain (or segment) – which means collectively they contribute to the overall enterprise solution with the cross-segment reuse potential facilitated by enterprise architecture governance.

If strategic level business architecture is not done as a part of enterprise architecture, then the following could be some of the risks:

• The segment/domain architectures will be disconnected with no sharable business or IT services.
• It costs more when cross-segment integration is required. How much it costs the business if the enterprise maintains, for example, four billing systems – which is the case in some telecommunication organizations.
• Business may make wrong technology decisions because of the disconnection between EA and business.  A good example is the case with the cloud services where the business directly buys services in a cloud (e.g. Salesforce.com services) and fall in to vendor lock-in situation. The vendor lock-in is highly likely if there is no strategic alignment between business and IT facilitated by Enterprise Architecture. That is why SOEAF includes strategic architecture that deals with strategic aspects of business and Information Technology. With the power of the strategic work, the enterprise can benefit from cloud service providers without risking the vendor lock-in situation.  
• Enterprise cannot see one common view of its customers – For example, I am a customer of one service provider where I have two services (i.e. wireless and landline phone services). My profile is maintained in two places as if I am two customer because the two business lines (business segments) are architected in siloed fashion with no enterprise strategic architecture. One business segment have no idea that I am a loyal customer of the other segment of the same enterprise. Does this ring a bell to you? – “One moment, I will transfer you to the wireless department” says the landline department of the same company; due to the lack of cross-selling capability of the enterprise. You are put on hold with music waiting for the other customer service (wireless) to serve you. You have no time to wait and you hang-up the phone. What a loss – the enterprise just lost one customer!

Yes, it takes a lot of work and re-organization to incorporate such a strategic architecture in an organization with more than one business segments. It may also cost more initially for the transformation. But all the effort and cost invested in strategic architecture pays off overtime with much more stability  and competitive advantage for the business of the enterprise.

Awel Dico

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:

• Teams (people): SOEAF involves multiple teams working together at different levels. For example, EA, Domain architecture, Governance, and development and operations/Infrastructure teams are the main teams.
• Processes: SOEAF is supported by three main process types. These include: architectural process (i.e. TOGAF ADM), Governance processes, and SDLC process.
• Tools: Each team mentioned above needs proper tools to do the job.

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

In part 1 of my post I introduced what is involved in end to end SOA work. In that introduction I introduced five key elements – also repeated the diagram below. I want to give a description of the elements in this post.

End to end SOA elements

Elements Description

• Enterprise Business Drivers, Vision, Strategy, Requirements

The business element is concerned with understanding and developing business strategy, goals, drivers, requirements and processes as a part of overall business architecture. This is the whole enterprise business view from which business needs that drive SOA work are identified. This is critical in that a successful SOA approach requires good business knowledge. SOA requires the knowledge of both business and technical worlds. If one attempts to approach SOA simply from technical perspective, it may not solve any business problem and business doesn’t see the value. Enterprise architect must have understanding of the business as well as the technology that addresses the needs of the business. SOA is better viewed as an Enterprise Architecture approach that encompasses the business and technology worlds. Moreover, understanding this scope of SOA is important in using TOGAF for SOA work.

•  SOA Preliminary Stage

With the overall business strategy, requirement, direction, vision, etc.. as the driver, the initial architecture work involves developing direction, processes, and guidelines to guide the subsequent elements of solution architecture work. The following artifacts are delivered at this initial stage:

Statement of direction (and scope), Architecture principles (existing EA principles as well as new SOA principles), SOA Governance and change management process, SOA Reference Architecture, Architecture patterns, guidelines and standards.

These are just some of the pre-requisite for SOA  based solution architecture work. Depending on your situation you may add to or remove from this list of preliminary deliverables.

• SOA Solution Architecture

Guided by enterprise direction, guidelines, standards and SOA reference architecture, the actual solution architecture work commences to address concrete business requirements. The input to this architecture work is concrete and specific business requirement. Multiple projects, each with its own concrete business requirements and architecture work, can be initiated simultaneously in a given enterprise, which is the most likely case for large organizations. All of these projects are then guided by the guidelines, standards, SOA reference model and Architecture supported by governance process. The architecture/SOA governance makes sure that the various projects comply with the enterprise guidelines and standards which are deliverables of the initial stage discussed above. The architecture work here is expected to deliver the following artefacts:

1. Business processes to address the specified business requirement.
2. Services architecture to support business process enablement.
3. Data and metadata models that are used in business process and services.
4. Technology architecture to support business process and services realization

May be other based on your specific requirements.

• SOA Solution Implementation

Solution Implementation is not architecture, but a realization of the architecture. Though implementation is not part of the architecture, it is part of end-to-end SOA work. It is only through implementation that the architecture’s value is realized by business. The solution implementation stage includes the following:

1. Development of the solution
2. Testing
3. Monitoring and managing.

It is only after services are developed, deployed and managed that the business sees the value. Services are deployed, monitored and managed in an infrastructure that is specified by the technology architecture as specified in the solution architecture part of the work. Services are composed or orchestrated to implement the required business process.

• SOA Governance

This element is concerned with end-to-end governance of the SOA work. How do you keep consistency across and assess compliance with the architecture, guidelines and standards? How do you manage exceptions to minimize the associated business risk and reduce overall costs? How do you collaborate with various projects and provide them assistance with enterprise guidelines and standards? These are just few of the questions that need to be addressed in this element.

Awel Dico, PhD

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.

Awel Dico, PhD