The Open Group released TOGAF version 9.1 today. I was just looking at things that have changed and thought you may be interested to know the major technical changes to TOGAF 9.  There are other editorial and minor technical changes made to TOGAF 9.  I only summarize the major technical changes below. For detail changes, there is a document listing it on the Open Group publications web site:    

•  Section 2.11 (A TOGAF document categorization model) is removed

The model is not being used for its stated purpose – to structure the release management of the TOGAF specification. And there is also some concern that it causes confusion

•   Major technical changes to section 5.5

Changes are made to use consistent terms here and in the levels, iterations, and partitioning chapters. This includes changing the order of the listing of the dimensions. Figure and text describing “progresive architectute development” updated/removed as it is the only place in the document that is mentioned. And some other changes to this section.

• Major technical changes to Chapter 20

Section 20.1 is replaced with better overview description. The diagram about architecture landscape is revised and much of section 20.2 is moved to chapter 19 and replaced. Section 20.4 which discusses about ADM Cycle approaches is removed and the content moved to chapter 19 and revised.

• Major technical changes to chapter 22 – Using TOGAF to Define and Govern SOA.

This chapter is replaced by the content from recently published Open Group guide on using TOGAF to define and govern SOA. This guide was developed by the Open Group SOA Working group. By the way, I was a co-chair of this project. As a result most of the content of this chapter is replaced by new content.

• Major technical changes to chapter 37 – Building blocks

Section 37.4 (Building block example) is removed because it is outdated example that is not fit with the new content.

• Major technical changes to Chapter 40 – Architecture Partitioning

The following sections are removed or replaced. Section 40.2 (Characteristics of Solutions), section 40.3 (Characteristics of Architectures), 40.4.2 (Partitioning Reference Models to Encourage Good Practice and Re-Use), 40.4.3 (Enforce Corporate Policy though Compliance with Standards), 40.4.5 (Activities within Phases A to F), and 40.4.6 (Activities within Phases G to H) are removed.  

• Major technical changes to Chapter 41: Architecture Repository

Figure 41.1 is changed - removed the Architecture Continuum categories from the Reference Library box. Added the Enterprise Repository. New sections added to this chapter discussing Architecture repository, Requirement repository, Solution repository, external respository, external standards, and Architecture Board approval.

• Major techical changes to chapter 42: Tools For Architecture Development

Section 42.3 (Evaluation Criteria and guidelines) removed because the guideline doesn’t reflect the current best practice.

These are the major technical update to TOGAF 9. I did not list here the major editorial changes. There are also other technical updates made in many of the chapters. Full change description is found at the Open Group publication web site.

I met my long-time friend this past weekend and as we are trying to catch up with our updates to each other, the impact of social media on business discussion came up. He works in insurance company and he sees customers making decisions about their insurance services based on comments, recommendations or experience from other social media friends. We talked about how the insurance company (or any other business for that matter) could minimize the impact and positively interact with customer (or potential customers) by listening to these social media channels. I then thought of the role of enterprise architecture in social media strategy and sketched how enterprise architecture could help deal with such a problem domain. I just want to share with you the thinking and hopefully get your comment on this to understand more about it.

Assuming that an organization/enterprise has EA capabilities in place, I think the following are what need to be done within larger scope of enterprise architecture:

• Understand the social media related business problem for the enterprise. This may include the following items:

- Identify internal and external stakeholders and document their concerns related to social media content integration and handling: Security concerns, Business concerns (loss of customer, brand, etc.), Technology concerns and other

- Create vision on how to deal with and address these concerns.

• Identify and model business processes to handle social media events. This may inclide the following:

–      Identify business areas that are susceptible to social media situations

–      Define information model that include social media event types

–      Use service orientation principles and Identify business processes and services within those business areas

• Position the identified business services and processes for automation. This may inclide the following:

–      Service architecture with the right granularity of services and interface/contract definition

• Implement the process automation using appropriate technology. This may inclide the following:

–      Service implementation

–      Infrastructure architecture/design

–      Consider Event-driven SOA and Sense and respond patterns/approaches

• Management and Governance. This may inclide the following:

–      Change management

–      Architecture and implementation governance

I draw the folloing simple picture on how to model / architect the customer (or potential customer) event handling and interaction. 

Dealing with Social Media - How to listen and respond to your customers on various channels

The key part in this model/architecture is:

• Listening to your customers (potential ones) via social media monitoring and capturing business relevant events. These events may also be from your existing customer channels (for example Online banking or insurance customer portals)
• Analysing this events by mapping to the enterprise information model and generate the key information to feed into your business processes.
• Business processes should be adaptive and responsive so that it can help interact with the customers in a context aware manner.
• The need to interact back with the customer / potential customer in real-time (or near-real-time) through their social media channel. If the events are from your existing channel, you should be able to interact back to the customer on the same channel in real-time (or near-real-time).

See you later – Thanks for visiting … Awel

I am referring to the enterprise vision in the context of enterprise architecture vision. It was clear (bright sun shine with no cloud in the sky) and every enterprise focused its vision on technology as a competitive advantage – business applications and their infrastructure were differentiators.  Enterprises invested heavily on in house IT departments developing business applications and infrastructure. Overtime things got complex and values from those investments fail to match the cost. Enterprises turn to initiating enterprise architecture programs – Enterprise architecture initiatives try to align business and IT to maximize the value from those investments. As this is ongoing, the sun shine started to dim and the cloud is threatening to take over.

The cloud is coming with large momentum and I think the enterprises need to change the vision to help see through the cloud and take advantage of it. Unless the vision is changed, the cloud is going to cover the environment – making it hard to keep up with the marathon race (run). Those who are quick in changing the vision are actually using the cloud momentum to sprint even faster and will be the winners. It is interesting that the experience you have running in the sunshine (no cloud) would not help you run in the cloud. This means new runners with the right vision can still be a winner in the cloud.  This is because all competitors have equal chance to leverage what is in the cloud – it doesn’t take army of developers to develop business applications and infrastructure. All that is required is to identify what you need and get those from the cloud.

So what are the key parts of vision that need to change to keep the enterprise in a race and eventually win? It seems if cloud is going to get bigger and stay around, a heavy investment on in house application and infrastructure development may not help. What is needed is a clear focus on Information architecture/model and the corresponding responsive business processes.  In the near future these two elements are where the enterprises need to look for competitive advantage.  The following example may help understand what I am trying to say.

 Consider, for example, current social media explosion. Those who are benefiting from social media are those enterprises with listening, analyzing and responding capabilities within a narrow time window. Listening is about information – what information out there is having an impact on my business? For that to be practical, the enterprise should have information model (or architecture) in place to properly listen and analyze the social media contents within its own business context. The information analysis should be in such a way that it can identify the impact on the business and guide the response. Response here is about talking back to the customers and their social networks using the appropriate language they understand. It is because of this conversational nature of the response that “time” is critical. If it takes you weeks to listen, analyze and respond – forget it! When you try to talk back, your audiences are gone with some feeling (positive or negative) about your business.  

So, what exactly I mean by “respond”? You need to know how to respond to your customers talking to you via social Medias. If you are thinking of marketing style of posting messages on Social Medias as you see it fit – then that is not what I have in mind. That is not really strategic and I don’t think it is effective way to respond. What I am thinking is about a change in your business process that deals with customers. You need to re-engineer your processes to be able to consume the information analysed in real-time (as described above) and behave accordingly to answer customer concerns in near-real-time (before the customer departs – may be to other service provider).  Your business process also needs to maintain the subsequent conversation with your customer on the same topic – with the possibility of real time customer-interaction.

Going back to the question – what are the key parts of vision that need to change? – I discussed with the social media case example above that your information architecture/models and your corresponding customer facing process should be the major focus of the enterprise to stay in the race when cloud overtakes.

 The Open Group SOA Working group has published (on May 06 2011) a guide on using TOGAF to define and govern Service Oriented Architecture. This guide discusses SOA related enhancements to TOGAF and highlights SOA artifacts produced at each phase of TOGAF ADM. The guide also discusses the enhancements to newly introduced TOGAF 9 metamodel. It is very concise guide that links many of the standards and frameworks produced by the Open Group working groups. For example, Maturity framework, SOA Governance framework and SOA reference Architecture are discussed where appropriate in the guide. I was a co-chair of this project and I would be more than happy to discuss the comments or questions you may have on this guide. The guide is downloadable from the Open Group web site at:

 https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12390

Update: See laso my related blog on the Open Group blog site:

http://blog.opengroup.org/2011/06/15/new-open-group-guide-shows-enterprise-architects-how-to-maximize-soa-business-value-with-togaf%C2%AE/

SOA is no more a buzz word and many organizations are benefiting from their SOA investments. When I say SOA, it includes Business services, Infrastructure Services and the associated governance – which are the keys for realizing the value from SOA approach. This post is not to discuss the value of SOA (which I think is well understood now). I rather want to explore the following question: What does the SOA target state would look like for those enterprise wanting to be agile, adoptive, and responsive in their business execution?

I think the target state should include the following elements (depicted in the figure below) :

• SOA based services implementing core business capabilities at right granularity to enable reuse and disable redundancy. These services include business process and entity services (also referred to as data or information services) implementing core business capabilities of the organization.
• Service oriented infrastructure services to support the core business services. These services include security services, management services, monitoring services, and any other services that may support the deployment, consumption, and Service Level management of the automated business services.
• The private cloud infrastructure in which the above mentioned services (business services and infrastructure services) are hosted. This infrastructure should enable service virtualization and be implemented as PaaS (Platform as a service) and IaaS (Infrastructure as a service).
• EDA (Event driven architecture) and CEP (Complex Event Processing) to enable reactive and proactive handling of business situations.
• Enterprise Service Bus to (1) decouple organization’s core services from consumer channels and external partner services, (2) simplify integration. All connectivity from consumers, partners and cloud services to the core business services should go through the mediation services of the Enterprise Service Bus (ESB).  To enable these, the ESB should provide infrastructure capabilities such as location transparency, protocol and message transformation, support for multiple protocols and message interaction styles including event pub-sub and transaction support.
• Public cloud services strategy  (i.e. consumption and integration strategy with a public cloud)
• Governance around the above elements to manage technology/SOA associated business risks while enabling innovation.

Conceptual SOA Target State

The path to the target state could be long or short or in between depending on the SOA approach the organizations take today. If organization’s current SOA approach is contributing to the repository of core services implementing organization’s core business capabilities, the path to the target state may be short (as each SOA service implementation adds to the sharable core services repository). If organization’s current SOA approach is very tactical in that it is purely bottom-up without guidance from organization’s core business capabilities, then the path could be long (as the contribution from each SOA service implementation to core services repository is minimal (or none). Enterprise Architecture plays very important role in realizing the target and achieving the expected value from SOA investments.

To start with, the Enterprise architecture needs to understanding the organizations current and target operating model which describes the business processes, people and technology components. Architecture is needed because of some understood or anticipated change in the way organization’s business operates. If there is no change, there is no need for architecture! So, the Enterprise architecture must understand WHY the change is needed and WHAT is going to change as a result. For example the change can be business process re-engineering or may be complete or partial business transformation. By understanding those WHY and WHAT of business changes, the enterprise architecture provides the target architecture and roadmap on HOW to implement the required business change. That involves indentifying core business capabilities and supporting IT capabilities. Both business capabilities and the associated enabling IT capabilities should be architected, designed, implemented, and deployed in a shared-services mode. Therefore, the identification of the core capabilities (both business and IT) and providing their architecture description is a key role of the enterprise architecture. In addition to that, the enterprise architecture plays a major role in the associated architecture governance and implementation governance (compliance with the defined architecture). That way the organizations’ on-going SOA investment can incrementally add to the shareable core business services repository (continuum) and enable organizations to respond to changing business situations and move innovatively with the ever moving target.

Awel Dico-:)

Do you have a challenge to justify the value of EA to the business? Do you get push-back from development teams to follow the architecture you developed? Is your architecture viewed as a burden instead of part of the solution to business problem? If you answer “yes” to any of these questions, the problem is not from quality of your architecture – it is the lack of effort on your side to engage the various stakeholders of your architecture.   

Stakeholders matter

Architecture is there for reason – to solve business problems (e.g. business improvement and/or business transformation). You must communicate (in business terms) to the business stakeholder how your architecture is going to addresses a given business problem. If that is not the case, your architecture will not be funded (approved) and the value is NIL.  Business team is not the only stakeholder that you have to pay attention to, but also other stakeholders in your enterprise including Operations team, Information Security team, Development team, Governance team and others such as external partners. However, not all stakeholders are always critical. You need to identify those key stakeholders that are critical for your architecture success.

If you are using TOGAF ADM for architecture development, this (i.e. stakeholders concern) is normally done in Phase A of the ADM – where initial architecture vision is created and approved. If the identified stakeholders do not approve the architecture vision, the architecture activity must be aborted at this stage. So, it is critical to listen to the various stakeholders concern and communicate to the stakeholders how the architecture will address their concerns. It is this communication that requires unique ability from the Enterprise Architect to speak in the language of various stakeholders using different architectural views.

All successful SOA implementations have one thing in common – Governance! Five years ago I shared my thoughts on my blog discussing the three major work streams required for successful SOA implementation. Establishing SOA Governance is one of them. The Open Group SOA Working Group have developed and published an SOA Governance Framework so that organizations adopting SOA can leverage best practice SOA Governance. Organizations will save time and money by adopting those governance best practices provided in the framework – i.e. do not have to re-invent the wheel.

You can download the framework from the Open Group site and also listen to the webinar recording on the topic – click on the link below.

Listen to the webinar recording here

The webinar provides an overview of the SOA Governance Framework and describes the value of adopting a standard method using the SOA Governance reference model and vitality model. You will gain an understanding of the framework processes, guiding principles, roles & responsibilities and benefits. You will also learn how to apply the framework to different organizational circumstances to enhance the usage and reuse of resources (people, technology, processes) and optimize business results.

Let me know what you think of the framework by commenting on this post.

Bye for now -:) Awel Dico

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.

• Either the architecture is shelved without real implementation because of cost of unrealistic roadmap or plan resulted from lack of current state understanding, or
• The architecture implementation is done with considerable cost with less value to the business stakeholder.  Again due to the lack of current state architecture the target architecture implementation cannot correctly address the challenges or issues that needed to be solved. Moreover, it takes longer time to get to the target because of poorly understood current position.

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

I came across a blog by Richard Veryard on architectural principles. He argues against the importance of SOA/EA principles by stating that “they may have some limited use, but they are not strong enough to bear the weight that is commonly put on them”. This is only true if the architect misunderstand what the architectural principles are or the architect is unable to link the principles with the reality and measure them. How can you measure the applicability or usefulness of architectural principles? I will share with you my 2 cents thought on this.
Enterprise Architecture, SOA or any other architecture, for that matter, needs to be guided by certain architectural principles. Where do these principles come from? Well, in the first place, the architectural principles must support the Enterprise architecture objectives/goals (which in turn must be driven by business objectives or strategies). That means the principles you put together or use to guide your architecture is not just from no where. They have linkages to the business objectives. For example, the business objective may be to be the best in customer service/satisfaction – customer centric. So, the Enterprise Architecture objectives must support that business objective. The principles must be developed to guide to achieving that business objective (customer first). Your architecture will then be guided by those specific principles.
There is a challnge though. Let’s say you have an architecture that is in compliance with the priniples. But, how do you know the architecture get implemented without losing the core priniples? How do you measure the effectiviness of your priniples? Unless you make sure that they are implemented and you are able to measure the effectiveness, those priniples may be disconnected from the reality (i.e. deployed business solution); in which case Richard’s argument may hold. Here is how you may measure:

1. Develop specific guidelines based on those principles. These guidelines are NOT abstract – rather they are concrete guidelines that the solution architects, developers, etc use. The developers may not understand the “abstract” principles. You need to translate the principles into concrete guidelines that they understand. To make sure that a single principle is properly followed, you may have to develop many clear and concrete guidelines that the developers use. By doing so, you are saying that “if those guidelines are followed and implemented accordingly, the principles are followed”.
2. Put together the metrics based on the compliance with those guidelines. Here is where you make sure that your principles are followed through compliance with those concrete guidelines. Here you need a governance process to assess such compliance. How do you measure the effectiveness of the principles? Well, your metrics need to include business related metrics in addition to low level metrics. If the business is happy – you know -:). Your principles are not effective if there are many “exceptions or problems” in complying with your guidelines. In which case you may have to review your principles (or the guidelines that represent them).

If the right principles are developed based on EA objectives (which support business objectives) and the implementation of those principles are followed down to the solution deployment through concrete guidelines (which are meausrable), then priniples are very important for any architecture initiative.

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:

1. Enterprise or Organization needs: What is that the enterprise trying to achieve (business drivers) and what is the maturity level of the EA in that enterprise? Is the enterprise ready to undertake complete or partial business architecture to drive Information, services/applications, data, and technology architectures? Or is the focus on information, applications and technology aspects with limited business architecture effort? What level of governance is needed? How good is the existing EA processes to accommodate the applications/services development (in other words, how integrated is the EA process with the common SDLC processes)? Many more such questions need to be asked to properly customize the EA frameworks in such away that the newly customized EA framework can effectively support moving the enterprise from current state to the target state (or achieving the target business objectives). What this means is that newly customized EA framework should help in addressing current and future enterprise challenges. One important thing to note here is that the customized EA framework is not “final or static” by itself – it needs to be positioned to evolve with the enterprise needs.
2. Architectural style adopted or in use in the enterprise: For example, if the enterprise is adopting SOA style, then the EA framework must accommodate such an architecture style to be of value to the enterprise. Failure to recognize this aspect of customization to the framework leads to disconnected EA work and SOA projects. This is real and you may have experienced such a challenge – i.e. SOA and EA viewed as separate streams of work and a communication gap between the two teams created.

   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.

Bye for now -:)

Awel Dico