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

It is kind of common now to associate SOA with Service Reuse. Yes – reuse is a very good thing – why spend much more money and time if you can reuse. If a service is reusable, in addition to contributing to business agility, it is also “green service” – environment friendly as well. The question is – How exactly is service reuse achieved? Many have been disappointed by the results they see in their SOA initiatives because their primary measure (metrics) for their initiative is Reuse. They lack clear understanding of what the service reuse is and how to get there. They assumed that service reuse is a given thing once you initiate SOA. The reality speaks different language from the assumptions. I used to preach to my team service reuse is one of the primary goal and want the team to deliver reusable service from the start. Overtime, I tracked the services deployed and only few services had the potential for reuse. Why? – I tried to find reasons why Service reuse is such a very good thing but wrapped by illusion.

Some of the reasons I listed include: Service interface and data not propoerly designed, service components not well designed, service level not properly incorporated, requirements not understood creating issue with service granularity and functional limitation, etc… You know what? … these and many more could be a reason to the problem. But, is that really a problem? Can one avoid these pitfalls by doing everything perfect and achieve the service reuse needed? The answer is NO! Yes, for simple cases where you can do perfectly and get reusable service – say across multi-business domains or multi-channels. For large organizations with many lines of businesses (or domains) it is not easy to get reusable services for cross business domain reuse. I came to understand why Service Reuse is such an illusion in many cases and what the organizations have to do to achieve reuse.

Here is my learning in the field -

1. First recognize that achieving (or getting to) service reuse in SOA is a process – i.e. a service may have to go through some iterative cycles to be close to perfect for reuse across multi-channel and multi-business-domain. It is proved to be hard to arrive at reusable service by just one shot! For large enterprise, this is mainly because of the lack of proper understanding of the complete requirements across the lines of businesses. This is the case today as the projects are mainly driven by lines of businesses bounded by cost and time. You may argue that enterprise can invest in completing cross business requirement understanding and absorb the cost for making service reusable. If so, you may have to add a “market factor” to this – the business line has urgent need to enhance its business capability to meet customers’ demand and cannot wait horizontal enterprise requirement analysis.
2. Second, recognize the importance of good service design to achieve enterprise service reuse. The evolution of your service towards reuse ( or in other words, your path and speed to reusable service) depends on the quality of your initial service design. Taking the #1 above into consideration, if your service design is not done well to position for further evolution of the service for reuse, you will have to redesign the service or end-up with duplicate non-reusable services across the enterprise – defeating the overtime “green service” vision of SOA.
3. Third, understand that enterprise service reuse requires strong SOA governance to facilitate the service reuse process. This goes into Service portfolio and service life-cycle management for the enterprise and more…
4. Fourth, recognize that SOA infrastructure can play a major role in facilitating enterprise service reuse … more on this in my next blog postings

I will try to share some detail toughts on this later… Bye for now.

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

It seems there is still some confusion out there as to what a “Service” means in the context of Service Oriented Architecture. Just recently I came across a discussion where “service” is being communicated as just a simple web services interface. That is why I thought of sharing here the definition I used in a presentation about SOA over a year ago. I used some concepts from OASIS SOA Reference Model and added other aspects of service that I think are important. The diagram below shows the anatomy of SOA service – what it really means when we say “Service” in the context of SOA. The usual common picture people use to communicate SOA based service is by using the triangle that shows service provider, service consumer and service broker or registry. What is more important and most of the time not clearly explained is the other view of the same triangle I overlay in the diagram below. That is, service has a description, service has implementation and service is governed. 

Service Anatomy - What Service means in SOA

In short, the following aspects of “service” are implied or need to be considered when one speaks of service in SOA:

• The usual high level view
  • Service has provider
  • Service has consumer
  • Service has a registry
• The other view which is more important is:
  • Service has description. This includes tasks that the provider has to worry about to meet the consumer need and how service can be used by the consumer (for the definition of these terms please refer to OASIS model linked above):
    • Contract
    • Interface
    • Reachability
    • Metrics
    • Functionality
  • Service has implementation. This includes tasks that the provider has to worry about to meet the consumer expectation of the capability of the service :
    • Design (you know how this is important too -:))
    • Code (you know … this is where the meat is -:))
    • Test (yeah.. you think this is not important? In most of the cases this is where the money is spent – cost. You must deal with on the strategy on how to test SOA services)
    • Package (yeah… you think this is not important? Think again… this is related to service versioning, migration, change management etc.. issues. You better have a good strategy on how to package the services implementation before they get deployed)
    • Deploy (considerations of performance, scalability, availability, and other operational needs)
    • Secured (this is missing from my previous diagram – but i think it is important aspect that must be considered)
    • Monitor (why? you must capture some metrics to evaluate if the service is of value to the business as expected. This metrics comes from the top level business service design because that is where they identified as important factors to capture for business use (mostly referred to as KPI). There are also operational metrics that are collected to meet operational requirements – e.g. capacity planning, trouble-shooting, etc…)
  • Service is governed. This includes tasks that the Enterprise Architecture has to worry about:
    • Standards (i.e. service may have to be compliant with some industry standards. Those standards are best specified by enterprise architecture)
    • Guidelines (i.e. enterprise architecture should have SOA principles from which some measurable guidelines can be derived. Services need to be compliant with these guidelines, otherwise the principle is considered not applied)
    • Compliance assessments (i.e. services should be assessed against the specified standards, guidelines or principles for compliance by the governance team)
    • Exceptions management (i.e. it is a reality that a given standrd or guideline may not be followed in under some circumstances. For example the cost of implementing the guideline or standard may not be justified at the moment; and as a result a non-standard approach may be used to implement the same capability required by the business. This is about weighing the pros and cons of such a decision and if allowed then the governance team need to manage that exception. The exception is normally temporary. However there are cases where the exceptions reveal a defect in the principles or architecture itself.  This is mostly the case if too many exception is granted as a result of violation of a given standard or guideline. In such situations, the architecture or principle need to be reviewed and the broken guideline need to be updated accordingly.)

 In the above discussion, I did not mention where the service we talked about came from – I mean its granularity, usefulness from business needs perspective, etc. I assumed that a “service” we talk about here is based on top level service architecture as a part of enterprise architecture. See my discussion on Service Oriented Enterprise Architecture Framework which puts the “SOA service” discussed here in a bigger context.

From end-to-end perspective, I think when we say “service” in the context of SOA, we need to understand the above aspects of a SOA service – its complete anatomy.

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

 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 you know the new version of  TOGAF (i.e. version 9) has been released this year with much improvement compared to the earlier version TOGAF 8. I am sharing my reading note below for those who need a quick overview of TOGAF 9 content and want to know the major changes from TOGAF 8. The digram shown below provides a high level summary of how TOGAF 9 contents are related.

Understanding TOGAF 9

Architecture Development Method (ADM)

The main part of TOGAF is the Architecture Development Method (ADM).  If you are new to TOGAF ADM, please see TOGAF document here. TOGAF ADM is an iterative architecture development method divided into phases that guide end to end architecture work. It describes what needs to be done to create an architecture.

Overall the structure and the core concept of ADM process is not changed from what was in TOGAF 8. Some more detail contents have been added to TOGAF 9 ADM and some clean-up is done; i.e. details about input and output chapters of the earlier version is moved to another part newly introduced in TOGAF 9 – Architecture Content Framework (see below).

ADM Guidelines and Techniques

This part of TOGAF 9 provides a collection of guidelines and techniques that can be used in applying TOGAF ADM. If you are about to use TOGAF, I recommend you read this part of TOGAF for some tips and ideas on how to apply ADM. After all the use of TOGAF for your organization requires some sort of customization to your needs – so, understanding some usage scenarios would definitely help you get started in that road.

Architecture Capability Framework

This part of TOGAF 9 provides a set of reference materials and some guidance on how to set up the architecture team – i.e. organization structures, processes, roles, responsibilities, and skills required to perform the architecture work. This includes establishing the governance bodies as well as evaluating the skills of your team to identify training requirements.  Overall, the architecture capability of an enterprise indicates its architectural maturity.  As discussed in TOGAF 9 document, mature architecture capability includes establishment of governance bodies, skilled resource pool, projects/portfolios, architecture repository supported by enterprise continuum – all to deliver solutions that are of value to business. Therefore, looking at Architecture Capability  is necessary to operate an architecture function within your enterprise.

Architecture Content Framework (ACF)

This is newly introduced to TOGAF. The main function of Architecture Content Framework is to ensure consistency within the ADM and provide guidance on overall architecture deliverables. Architecture Content Framework specifies what the architecture should look like once it is completed. In that sense it provides guidance on what to produce while working through ADM phases. It also guides the Architecture Repository to be structured as per content metamodel. The use of content metamodel also simplifies the work of generating viewpoints and views for stakeholders communication on demand.

Enterprise Continuum and Tools

Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of related architecture deliverables. Architecture Repository is where the various architecture deliverables are stored and managed. As you work through the ADM phases, you interact with the Architecture Repository in two ways – reuse and populate (store).  You need to look at the repository if there are any previous architectural building blocks that you can reuse. You also need to populate the Architecture Repository once you complete the architecture through the ADM.

As to what changed from the earlier version TOGAF 8, the Enterprise Continuum part is revised – existing content is rearranged and new contents are added. In TOGAF 8, the reference models are discussed in the continuum part. In TOGAF 9 this is moved to another part of the document making the Architecture Continuum part cleaner and clearer than before. New contents are added on architecture partitioning and the repository.

Stakeholders Viewpoints and Views

The use of TOGAF requires identification and addressing stakeholders concerns. That means as you work through the ADM, stakeholders concerns need to be considered. Moreover, it is important that you communicate to the stakeholders by addressing their specific viewpoints and creating compatible views from the repository as needed. After all, stakeholders are your customers and customers want to see what is important to them – not to you -:). Therefore, in putting together the Architecture Content Framework, you must consider stakeholders concerns. Architecture Content Framework  should identify the deliverables that are reviewed, agreed, and signed off by the stakeholders.

Awel Dico, PhD