TOGAF Demystification Series: TOGAF Doesn’t Play Well With Others

Fit Together

In this post in the TOGAF demystification series I will talk about how well or not so well TOGAF plays with other frameworks in the industry. In my last post this topic was brought up and I see it on the LinkedIn forums as well.

So let’s talk about this myth that TOGAF doesn’t play well with other frameworks. So what do I mean by that? The myth is that TOGAF is all about TOGAF or is monolithic in nature. This is far from the truth. TOGAF is a truly unique framework in that it really does embrace the notion of a better together story with other frameworks and approaches to solving problems. This better together story is all about bringing in other frameworks to complement, reuse and ultimately reduce the amount of duplicate methods in the industry. The thought process must be, if it works for them then it should work for us too. 

A great example of this is at the absolute core of TOGAF. A core concept of “Architecture” is not defined by TOGAF but rather by ISO/IEC 42010:2007 (formally known as IEEE 1471). Of all areas to define yourself and be justified, TOGAF doesn’t do so. It takes in the definition and applies it to the architecture framework. TOGAF provides guidance around the definition and meta-model given that it was created outside any one methodology / framework. 

Below is the actual text from TOGAF:

TOGAF considers the enterprise as a system and endeavors to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 – ensuring that usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard – and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to 3. Definitions and Part IV, 35. Architectural Artifacts.

As you can see above, while many other frameworks feel that they have to make it their own in an self-interested type of way, this isn’t the case with TOGAF. There is clear evidence that that TOGAF is doesn’t have the “must be invented here” syndrome  and will not duplicate the approaches in other methods. I applaud them for that level of leadership in the industry where it is a common practice in the overall technology and architecture fields respectively to do deliberately duplicate meanings, approaches and overall methods for doing things. 

One last area of note, in most phases in the ADM the first step is essentially to establish how you want to perform that phase. In this step you as the EA are to select the methods, approaches, reference models, architecture or standards and apply them to the problem you are solving in that phase. This is essentially saying is:

  • Not every architectural problem needs a prescriptive process. 
  • USE YOUR JUDGEMENT when applying architecture process and rigor.
  • If TOGAF doesn’t have something that solves your problem fill the gap.
  • Reusable architecture building blocks are the key to accelerating predictable results, TOGAF is architected to support this.

Lastly, TOGAF has published many mappings to other frameworks. In the specification you can find references to ISO, IEEE , PMI, Zachman and DODAF to name a few.

Below is a listing of some of those mappings (not all inclusive):

 

Note: Some of these mappings were done with older versions of TOGAF. However, there should be minimal gaps and provides the intent of a better together story. 

TOGAF Demystification Series: Comparing TOGAF to Other Frameworks

 Apples and Oranges

For the second post in the TOGAF Demystification series, let’s tackle the common topic of TOGAF to other frameworks. Over the years I’ve heard the debates between passionate EA’s and seen the seemingly endless posts on LinkedIn and blogs on this topic. One thing is for sure, this is a topic of much interest.  

While the driver is often to figure out if there is a better enterprise architecture framework out there, sometimes our enthusiasm gets the better of us and turns into a heated debate with a lose of the original reason why we need to choose a framework. 

This post will not go into:

  • TOGAF compared to [Insert Framework Here]
  • Detailed comparison of all frameworks
  • Why TOGAF is better or worse than other frameworks
  • TOGAF features and evaluation to other  frameworks  

Rather than directly evaluate or compare, I think it is more beneficial to take a step back. The goal here is to provide a way to think about comparing TOGAF. I do believe that not all roads lead to TOGAF. That is the reason for not publishing the reason why all of you should adopt TOGAF. I believe that is fundamentally wrong. You must look at what is important to your organization and make the call based on all those drivers. 

So in this post will will  look at the following:

  • what are the common misconceptions when evaluating
  • what approach should we use
  • is there a comparison frame of a mental frame for evaluating these frameworks. 

Simply put, this post serves as a way to think about comparing and contrasting frameworks.

If you are looking for an evaluation of frameworks, I have a resource for you. Back in 2007,  I ran the practice of Enterprise Architecture for the Architecture Strategy Team at Microsoft. At the time, my team contracted Roger Sessions to write, “A Comparison of the Top Four Enterprise-Architecture Methodologies” to be hosted on the Microsoft Enterprise Architecture portal that I ran. Since then it has gotten quite a bit of attention. It is due for a refresh as it is clearly out of date now. It was a good first start but needs more quantification and classification to really do these justice. I am looking at a refresh of that whitepaper and will have an update soon. Stay Tuned!

Apples and Oranges

I would like to start us off with the notion that not all frameworks are the same and not all serve the same purpose. In many ways these comparisons have been like comparing apples and oranges. For a number of years I have observed that architects tend to compare these frameworks as if they all were built with the same goal in mind. With this logic there is no real winners in the comparison, just confusion. 

TOGAF is routinely compared to other frameworks. In many instances it is unfairly compared to other frameworks that serve another purpose and/or outcome. We first have to split these into two areas:

  1. Area of Focus – Defines the disciplined area of focus of the framework.  Examples would be: Service Management, Program Management, Architecture Development, Software Development, etc.
  2. Type of Architecture Framework – A defined set of segmentations to identify the logical groupings of frameworks with similar origins, goals and outcomes.  

We first want to look at the area of focus when comparing frameworks. We want to make sure we are in the “same ballpark” when we compare. By looking at this we can use it as the qualifier to quickly see if we compare at all. For example, if you wanted to determine what is the idea EA framework for your orginization it doesn’t make much sense to compare frameworks ITIL vs. TOGAF or COBIT vs. TOGAF (outside edge cases where this is done deliberately). These frameworks have completely different:

  • problems it trying to solve
  • outcomes
  • supporting processes
  • stakeholders, suppliers and customers
  • deliverables
When we evaluate frameworks that were built to support a different outcome than the outcome we are looking for in EA the comparison is fundamentally flawed. 

Once we determine that we are “in the same ballpark” and comparing architecture frameworks, we then can look at the the types of architecture frameworks. 

Three major types of architecture frameworks:

  • General Purpose – frameworks that are purposefully generic in application and built to be highly reusable and modular to support a broad range of outcomes, industries, skills and maturity levels. Examples include: TOGAF, Zachman
  • Business Specific – frameworks driven by a set of defined business or industry concerns. Examples include: MODAF, FEAF, TEAF, DODAF
  • Vendor Specific – frameworks that are aligned to specific offerings provided by that vendors. Examples include: Oracle EA, Microsoft Value Realization Framework, Cap Gemini IAF (deprecated and merged w/ TOGAF)

Making Comparisons

So far we haven’t really talked about evaluating or comparing frameworks. What we have done is set some important data points for us that will be a large part of our evaluation.

According to Wikipedia, evaluation is defined as such:

Evaluation is a systematic determination of a subject’s merit, worth and significance, using criteria governed by a set of standards. It can assist an organization to assess any aim, realisable concept/proposal, or any alternative, to help in decision-making; or to ascertain the degree of achievement or value in regard to the aim and objectives and results of any such action that has been completed.

There are two key points that I’ve highlighted, merit (what I want to get out of this) and structured and governed criteria. 

A simple 7 step full lifecycle evaluation process that I use for an evaluation of an architecture framework has the following steps:

  1. Rational – Why I’m evaluating architecture frameworks and what are the key drivers. This typically will result in a set of the critical questions that need answered with some well structured criteria. 
  2. Identification – The goal of this step is to quickly and qualitatively to identify a “short list” of architecture frameworks that align to the problems we are trying to solve with the architecture framework (Step 1 – Rational). We do this by:
    1. Apply the rational or value driver statements to the list of frameworks available. 
    2. Architecture Framework Area of Focus (discussed above) – This allows us to quickly get to a smaller set of frameworks to evaluate
    3. Architecture Framework Type (discussed above) – This further cuts the list down to a finite set of frameworks. 
  3. Trade-Offs – With the short list of architecture frameworks go through a well disciplined trade-off analysis with the identification criteria above. This should identify all the change management challenges that you will encounter with people (maturity level, skills, etc.), tools / technology and process changes that will be needed. This should lead to the overall costs and benefits that address the rational subsequent value drivers. 
  4. Selection – The selection of the architecture framework with well defined implications of the decision with the criteria of selection. 
  5. Implementation – Phased implementation of the architecture framework. 
  6. Govern  – Established body that governs the architecture framework health with measurements of effectiveness in the organization. 
  7. Validity – After a period of time has elapsed (sometimes yearly) a life-cycle is implemented around the architecture framework to ensure that that the organization is getting maximum value out of the framework. 

 

Conclusion

When you are evaluating TOGAF for your needs there isn’t an easy or direct answer. You have to go through a process to determine what framework is right for you. This post nor a LinkedIn forum will be able to answer that question for you. Start with what is important for your organization. Meaning, what drives value for you. If you’re a government agency, it makes sense to start off with one of the popular government EA frameworks such as: DODAF, MODAF, TEAF, FEAF etc. If you are in an industry segment which has a framework defined like telecommunications then TMForum is a leading candidate.

Since TOGAF is a general purpose framework, I tend to look at TOGAF as a framework of frameworks. It is really built to be the “platform”. It was designed with reusability, modularity and assembly as first class citizens. It will not give you the prescriptive process, rather it is descriptive of the areas of concern and YOU choose what is “fit for purpose” for your problem set.  As I mentioned in my last post, this does add a layer of complexity but I do believe it provides the ability to come to the fastest possible value to market in an architecturally rigorous way.

If you are comparing TOGAF to FEAF or a vendor framework you are not comparing apples to apples. These architecture frameworks have different inputs and outputs in mind. Comparing TOGAF to Zachman is a closer fit. However there isn’t many more general purpose frameworks that are “open source” like TOGAF. A fair comparison would be MODAF vs. FEAF or Microsoft VFR to Oracle EA Framework. These are comparing the same value drivers. But when you mix these types it causes confusion and endless debate. 

If you are looking for extended information on this topic I will be writing a full whitepaper going into an extended look into the process, the framework and a EA Framework Evaluation Matrix that will compare a set of the common EA frameworks on the market based on a set of attributes (outside a specific EA organization need) in a qualitative and quantitative way. If you want a sneak peak at the drafts or you want input into the process leave a comment below.

TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex

True or false

Do I have your attention now?

Given this is the first post of the series about the myths, misconceptions, fiction and even some facts  behind TOGAF I want to be open and honest about my affiliation with the Open Group. I do have personal affiliations with the Open Group. Like many others, I am certified as an Open CA Distinguished Chief Architect, I have participated in the Architecture Forum building out TOGAF v-Next and I speak at their conferences. However, I am not financially or otherwise compensated by The Open Group. My interest is my own and to evolve the EA discipline. 

Now let’s get into it.

So just to set the record straight, I don’t believe that TOGAF sucks. Quite the opposite. Does it need work, yes. Are there areas in which I would do something different, yes. But like anything else I think it’s a work in progress but thats no different than anything in the EA space. 

This generalization of TOGAF not living up to the right level on the quality bar can be found all over the place (e.g., Linkedin, Twitter, blogs and even in competing training organizations) . To be perfectly honest it seems like people either love or hate TOGAF. But why is this the case? Surely with such a pervasive complaint there is merit behind it, right? Well with this one, yes and no. But we need to decompose this into three areas to first.

  1. TOGAF You Suck
  2. TOGAF is incomplete
  3. TOGAF is Overly Complex 

 

TOGAF You Suck

Wow, what a generalization. Many things might come to your head when referring to something “sucking’ (and yes that’s the technical term). Here are the common complaints:

  • Missing core elements
  • Hard to understand
  • It’s so long
  • Too Academic

I’m not going to address these items specifically as I will talk about them in later posts or refer back to them directly and indirectly. I would much rather take a step back and look at the macro point here. I’ll do so by telling a story about my own experiences and a negative perception that I had on TOGAF. 

So this story dates back to the mid 2000’s when I was still very skeptical of TOGAF and the industry was even more disjointed than now. I had used elements of TOGAF and had done a deep analysis of the framework. I looks at what a good framework and methodology should have along with the practicalities of applying to my company at that time. 

I went to the Open Group Architecture Practitioners Conference and sat through the TOGAF 101 pre-conference seminar (for the second time) and jotted down notes with all the gaps I had identified. I was thinking, “I can’t believe they didn’t think about that”, “what about [xxxx]?”, “that would never work…”

I wasn’t the only one with similar thoughts. At that time TOGAF was on version 8 and was still very IT focused. So that added fuel to the fire as well. 

Being the not so shy guy that I am I confronted a very senior member of the Open Group staff and had a very passionate conversation with them about my thoughts. This turned into a multiple hour conversation over drinks (thankfully for him) in which I proceeded to tell him my thoughts: “Let me tell you about this…”, “don’t you know you have a gap here?”, “I could never apply this…”

As the conversation progressed, most of my feedback was received quite well, even a great deal of agreement on what my view was. But at the end of what might of seemed like the Spanish Inquisition  for him, he simply replied back to me:

Those are all great ideas, why aren’t you participating to apply those changes?

He then proceeded with the statement that the Open Group itself doesn’t write a single line in TOGAF, it’s member companies do.

That was the ah-ha moment for me… A whole new perspective arose. It’ an important distention to keep in mind. It also reenforces an open source feel for EA once you understand that. I have personally been able to influence the standard, just in one meeting. If what you have is really compelling for the practice then donate it to the greater good. I see a lot of folks trying to monetize this and that causes further disruption in the practice. 

The Open Group provides a forum / platform / stage (or whatever you want to call it) for collecting industry consensus on what an Enterprise Architecture Framework should be. This isn’t to say that the current participants in the Architecture Forum  “suck”, but maybe there isn’t enough people participating or enough challenging of the status quo.

So I’ll leave this final thought on the topic…

If TOGAF sucks, aren’t we to blame? 

 

TOGAF is Incomplete

This is one I hear quite a bit as well. For me, this is a push (both true and false). 

Let’s start with the true piece. I think it’s fair to say that there are components that are missing from TOGAF. I will also say that there are elements of the method that could be enhanced. A great example of this is the Business Architecture phase. 

However, this is misleading. This gets us to the false aspect of this. TOGAF was built to be a general purpose platform that is extended. The intent of TOGAF is not to create all those modules (necessarily). At the beginning of most phases the first step is to establish what methods, models and tools you will use in that phase. There is a general “happy path” provided in the method along with some diagrams, matrices and catalogs. However, it is expected for the EA to know what to plug into the method, even if it is not TOGAF (which is recommended by the method). 

For many aspects TOGAF links out to other frameworks. This is a very good thing. If something works, don’t break, change, reinvent it. This happens so much in our industry. There is a level of humbleness about the approach that wants to create unity in the EA space. 

With all of this said, I think TOGAF provides a solid foundation. I would like to see more in the “Core” framework to fill those holes that are there, and there are many. That’s ok, in my honest opinion, TOGAF is the best universal general purpose EA framework out there that has the strength of the top 5 high-tech companies with a ton of passionate people behind it. It is a defacto standard for our practice with a ground swell of certified practitioners. 

 

TOGAF is Overly Complex

My first response to this is… What part of enterprise architecture isn’t complex. Of course EA is complex. If it was easy we would’t need it. There is a great deal of rigor and skill need to architect for enterprises. So let’s separate out two issues:

  1. Is the practice of enterprise architecture complex?
  2. Should the customers / consumers of an enterprise architecture framework be complex?

In the case is the EA practice complex, as I stated above, of course it is. Given that’s the case expect to see complexities in the framework. I think that is OK.

 However, to the second point with the consumption of framework I tend to agree that it is difficult (for some people) to consume TOGAF without formal training. I do think there are things that can be done to make TOGAF more consumable. But I don’t think that it has unnecessary components to it. I think TOGAF is more at the optimization stage rather than re-engineer stage.

For example, I have a dozen or so of my staff reading TOGAF as a study group. I find myself clarifying aspects of the standard quite a bit. Some of this is purely structural of the content, conflicts in terminology (for example the fully loaded term”capability”)  and the nuances in the intent of TOGAF. 

The second area in the complexity area is less about complexity and more about the sheer volume of pages in the standard. This comes to the degree where people refer to the book or online version as  the TOGAF Bible or the 900 page gorilla. This is where I get conflicted in my response because this statement is usually from the same folks that say that there isn’t enough in TOGAF. 

Is this a deal breaker for the usage of TOGAF? No.

The good news is that the members the Architecture Forum (where the TOGAF standard is created) already know this. We see evidence of simplification of TOGAF with 9.1. TOGAF 9.1 was a point release to address inconsistencies, duplications and other areas that these very issues. In TOGAF v-Next I would expect you to see a major update that would keep this in mind too. 

Conclusion

So what is the conclusion here? Does TOGAF “Suck”? Simply put, I don’t think so. 

I walked us through some of the common things I hear when people say TOGAF is no good or “Sucks”. Just like with anything I there is certainly work that needs to be done with the standard. However, it is clear that TOGAF has all the essential elements that you would want from an EA framework:

  • Open (Source) Standard Enterprise Architecture Framework that is driven by practitioners
  • TOGAF is MEMBER driven based in industry consensus
  • Industry standards setters on proven practices NOT to foster trends or fads
  • TOGAF is a general purpose framework that is built to apply to all companies of all sizes, in different industries,  supporting any organizational model and maturity of EA.
  • It has a method and a framework
  • Continually evolves and adds to the standard. A great example of this is architecture modeling with ArchiMate. 
  • Serves to partner rather than duplicate other standards. We see this with the better together materials on Zachman, TMFourm and SABSA to name a few.

It’s not perfect but I will go back to what are you doing to make it better. This is your call to action!

For the creators of “-AF” frameworks

  • Stop creating duplicate methods that are essentially or close to the same as TOGAF
  • Take the methods that would complement TOGAF and give back to the community. If you’re a consulting firm, take a page out of the IBM playbook. They donate a great deal methods and models that are common for everyone and the thing that differnates them (special sauce). That shows the industry that they are the leader and setting the standard. 
  • Before commenting on how bad TOGAF is, get trained in it (ideally certified). To protect the guilty I’ll omit names. I have sat in on training courses on other frameworks and I hear comments made about TOGAF that are just plain wrong. I have a problem with that as a practitioner. This send false information to EA’s which ultimately hurt our profession. STOP IT!

For the practitioners 

  • Ask yourself what are you doing to advance the profession and what you can do if you’re not.
  • Join an Open Group forum or workgroup
  • Take a step back and look at the broader industry. Take a look at another area such as Service Management with ITIL or Program Management with PMI and contrast it with the TOGAF approach. 
  • Get your colleges involved.

TOGAF Demystification Series: Overview

 

Confusedfew weeks back I sat in on a TOGAF 9.1 training course that I had my team ramp up on. This training was two fold, up-level the knowledge of enterprise architecture team on EA methods and it also served as a tool to understand the gaps in our own EA Framework (which is based on TOGAF) and enhance for our next stage of maturity.  

Throughout the training I observed several misconceptions, open questions and even some concerns with TOGAF. As I sat and listened I reflected on what I’ve heard about TOGAF in the past. They were all very similar to the debates I hear on Linkedin, Twitter, blogs and many other forums. Some have a lot of merit while others not so much. 

So, I jotted a few of the big ones down with a little bit of context and thought I would generalize them into something that would be useful for all of you to leverage or learn about. I am going to check the EA dogma at the door and be as factual as possible. It’s important for us to factually all about this topic and not get burdened by option or bias. 

 Below are the myths or facts I will create posts for in this TOGAF Demystification series. Expect this to flow out over the course of the next few weeks:

  1. TOGAF Sucks:  Incomplete and Complex
  2. TOGAF vs. [Insert Architecture Framework Here]: What you need to know about comparing frameworks
  3. TOGAF Certification is a Weak
  4. TOGAF Certification = Enterprise Architecture Certification
  5. TOGAF = Open Group
  6. TOGAF is too Ridged and Academic 
  7. TOGAF is a Framework
  8. TOGAF is Enterprise IT Architecture (EITA) not Enterprise Architecture (EA)

If there are any other topic you want me to cover, please leave a comment. I would love to hear your thoughts as well. 

Free TOGAF 9 Exam Simulator and Sample Questions

Manuel Di Toma has created a great resource for Enterprise Architects looking for TOGAF 9 certification. He built a set of TOGAF 9 simulation tests to help prepare you for the big test. 

Manuel ensures that all the resources in this portal are verified by TOGAF® 9 certified Architects. But please note, this website was designed and implemented by the Manuel; The Open Group is not directly involved in this initiative.

You can find the resources here: http://theopenarch.com 

In Manuel’s words he describes why he created the site:

When I was studying for my TOGAF 9 certification exam, I realised that there wasn’t any FREE website offering a reliable service to try and test your TOGAF 9 knowledge and GET PREPARED FOR THE TOGAF 9 EXAMINATION. For this reason I decided to build a simple test engine using a free PHP solution called Limesurvey to enable the online testing capability, then on top of it, I built a portal. But I decided not to stop there and extend the purpose of the Portal. The Objective of this portal is to spread Enterprise Architecture Best Practice and offer FREE Enteprise Architecture Resources to other Fellow Enterprise Architect

Other helpful resources include:

A Quick Look at the Importance of Information Architecture

With all the buzz at the Open Group Conference in
Newport Beach
this year around Big Data I thought I would take a small step
back and write a short post that looks at the importance and the linkages of Information
Architecture (or in TOGAF terms Data Architecture).

The importance of information architecture cannot be overemphasized. As architects we look
at solutions a bit differently than others in IT by focusing on solving
problems business first or top down. However, sometimes we get caught in the
trap of focusing on the most tangible aspects of our architecture while losing
track of the aspects that truly drive our architectural decisions.

Information architecture serves as that vital bridge from
the business architecture world to application and technology  architecture.  This is shown below, from both the widely
accepted Enterprise Architecture from NIST
and from the Open Group’s TOGAF Architecture Development Method
(ADM)
, you will see Information Architecture as the glue between business
and solution architecture.

Mike The Architect Blog - NIST and TOGAF 9

As shown above, information and data constitutes the most
basic and foundational of all information units employed by a solution.
Solutions are created to manage data and to help transform data into
information. But data is consumed in different ways by people, process and
technologies. While it’s a little dated, I really like how NIST puts this all
together in one model.

Having a clearly defined information architecture provides concrete
direction to the architecture. It provides a translation layer between the
business architecture and all other views. The Information view does this by
first identifying the required information that provides clear direction on how
the information should be created, manipulated, and analyzed. Through this articulation
of information the view will then identify the required technical capabilities
and specific technologies required.

A well-built Information Architecture should be able to
address how your architecture will provide:

  • Insight into how information will flow
  • Classification of information
  • How the business and applications should use and
    operate information
  • Map of information entities
  • Pathway for the creation of application
    definitions

 

Cloud computing architectures provide a tangible example of
why this is so important. To really determine what solutions can / should go to
the cloud we must first understand the data aspects. This ranges from functional
/ non-functional requirements to risk management and compliance. These aspects
have the ability to stop you in your tracks, and they are all data centric. 

Enable Cloud Strategy and Planning with Predictable Methods, Models, and Tools

Mike The Architect Blog - Cloud Strategy and Planning

We previously
looked at why cloud is so important (Challenge
the Status Quo and Advance Business through Cloud Computing
, ),
approaches to cloud strategy (Understanding
Which Investments Should go to the Cloud
, Cloud
Strategy Begins with Value and Balances Risk
) and who the best
people (Why
Enterprise Architects Must Drive Cloud Strategy and Planning
) are to
execute. Today we’ll examine the methods, models, and tools that the enterprise
architect should use for effective cloud strategy and planning.

Methodologies
As far as methodologies go, it’s usually
better not to reinvent the wheel. There are already proven general frameworks EAs can use, so try to leverage
what is already out there whenever possible. When using an existing
general-purpose framework like TOGAF, apply cloud specifics to it.

Using a framework like TOGAF can ensure that you
are not missing the critical steps, questions and outcomes that every good
architecture should have. This will also ensure that all the other architecture
work and this work is consistent and predictable with the outcomes it produces.
Below are a list of a few benefits for leveraging TOGAF as your methodology for
Cloud Strategy and Planning:

  • Broad Community – If a custom framework is built, very few people
    have expertise and experience. TOGAF has an extremely broad EA acceptance,
    adoption and certification.
  • Deliverables and ArtifactsTOGAF comes
    with a wealth of “out of the box” templates
    that can be leveraged to
    architect.
  • Linkages to SOA and Cloud IP The Open Group which manages TOGAF, has
    other forums  and working groups that
    builds content for specific architecture areas and domains such as SOA,
    Cloud, Business Architecture and Security Architecture to name a few.
  • Associated Cloud Standards Bodies – The Open Group has done a great job of
    uniting multiple specialized and deep cloud standards bodies with the TOGAF
    standard to bring together the best of both worlds. The general purpose
    framework applied. These partners include NIST, Cloud Security Alliance and more.
    All this work has come together in The
    Open Group Cloud Computing Work Group
    .

Below is a visual on how Cloud Strategy and Planning
extends TOGAF within this framework:


Mike The Architect Blog - Cloud Strategy and Planning TOGAF Method.jpg

Another great visual is from Serge Thorn where he shows this from
a native TOGAF view:

Mike The Architect Blog - Cloud Strategy and Planning TOGAF Detail

Check out his blog post, “Cloud
Computing Requires Enterprise Architecture and TOGAF

Is TOGAF the only methodology you use? No. Just
like any other architecture work there are many different facets other than
just architecture such as: Risk Management, Information Security, Project /
Program Management, Software Development and Operations. There are methodologies
and frameworks for each specialized area that complement your architecture
work.

Some things to remember when adopting methodologies:

  • Strategy Methods are Universal – The same macro/basic steps are the same
    and can be applied to most anything. Just like with anything you will have to tailor
    slightly to your needs. DO NOT REINVENT
    PROVEN MODELS
    .
  • Make General Purpose Methods Specific – These were meant to be applied to a
    specific problem set. Cloud is
    no different.
  • Use Extensions – Cloud tools and techniques such as CSA, NIST,
    and Open Group-specific resources can be very useful in giving general-purpose
    frameworks meaning.

 

When we apply these
aspects to a cloud methodology you get The Cloud Strategy and Planning (CSP)
Framework. It is comprised of three simplified phases and seven activities.

 
Mike The Architect Blog - Cloud Strategy and Planning Method and Act

CSP
embraces and extends proven practices in the industry and the industry
resources from the following distinguished bodies:

  • The Open Group (TOGAF)
  • Cloud Security Alliance (CSA)
  • NIST Cloud Computing Working Groups
  • Sherwood Applied Business Security
    Architecture (SABSA)
  • Cloud Security Alliance (CSA)

 

Activity Descriptions

Below is a high-level overview of the activities with the description of
what occurs in each. The detailed steps are not shown below.

Strategy
Rationalization

1

Establish Scope, and Approach

  • Conduct the Cloud Envisioning Workshop
  • Provide overview of cloud computing
  • Define the enterprise business model for
    cloud computing
  • Establish project charter

 

2

Understand Strategic Vision

  • Gather the IT and business strategic
    objectives
  • Identify strategic cloud computing patterns
    and technologies
  • Analyze customer feasibility and readiness
  • State strategic vision for cloud computing

 

3

Identify and Prioritize Capabilities

  • Define evaluation criteria for key IT &
    business value drivers
  • Evaluate the capabilities based on these
    metrics
  • Identify ~5 high-priority capabilities for
    deeper analysis

 

 

Cloud Valuation

4

Profile
Capabilities

 

  • Determine current state of capability
    maturity leveraging IO Maturity Tools
  • Execute Risk Analysis Method with
    corresponding assessments and remediation steps.
  • Profile the capability asset portfolios of
    information, technology, and processes and analyze by architectural fit, risk
    and readiness

 

5

Recommend
Deployment Patterns

 

  • Research capability proven practices and
    market direction
  • Define target cloud capability requirements
  • Determine optimal cloud service and
    deployment patterns for the capabilities based on fit, value, and risk

 

 

 

Business
Transformation Planning

6

Define
and Prioritize Opportunities

 

  • Completely define opportunities to
    include  an overview, benefits, risks,
    assessment results, technology impacts, and project plan
  • Prioritize opportunities for detailed
    architecture and execution

 

7

Understand Strategic Vision

  • Assess implementation risks and dependencies
  • Develop and deliver a business
    transformation roadmap
  • Validate with the customer and edit
    accordingly

 

 

Models

With respect to models, there are many out there readily available. Since
we are starting with  business value we
want to make sure we continue to do so and ensure there is a bridge from
strategy to implementation.

Mike The Architect Blog - Top Down Strategy

Given the top down
nature you will want to pull from models  that lend to our approach. When selecting
models, take a step back and ensure you fully understand the scope of what you
want to accomplish then select the most appropriate models from the many
sources at your disposal such as: analysts, standards bodies, industry bodies
or internal reference models.

For example, CSP
integrates SABSA to ensure that CSP has a classification scheme to capture business
requirements along with the identification, classification and management of risk.
The SABSA method focuses on the area of security while CSP extends this for cloud
computing. CSP incorporates a similar structure to SABSA and utilized the SABSA
matrix as a stellar example of using question-based analysis in IT
decision-making. By using the business requirements as the “red thread” through
the analysis, SABSA and CSP are both able to ensure that the business
objectives are being met. In the case of CSP, the business should be the
driving force behind the cloud transformation.

Mike The Architect Blog - SABSA Matrix

A common issue I
see when selecting models are that a model is selected either based on
preference or it is good enough. Don’t do that. Make sure you have a fit for
purpose model. If you don’t you may not get an accurate output.

 

Below are a good
set of models that can be used when rationalizing strategy:

  • Strategy maps
  • Business canvas
  • Hosen strategy
  • Net Present Value (NPV)
  • Business Scenarios
  • SWOT
  • Porters Five Forces Analysis
  • Motivation Model

Mike The Architect Blog - Strategy Map Example

Tools

 Now let’s talk about
the tools. These will allow us to automate the method along with helping align,
measure, quantify and qualify our work.

The tools below
will help

  • Charter – Template to authorize the
    project and define scope, stakeholders and timeline
  • Enterprise Capability Assessment
    Enterprise level 1 capability analysis to segment a customer’s portfolio for
    the discovery of cloud opportunities.
  • Business Heat Map – Graphical view of an
    organization based on business capabilities and cloud attributes like risk,
    value, fit and readiness
  • Capability Prioritization – Further
    refinement of each business capability with respect to cloud risk, fit and
    readiness
  • Capability Profiling – Rollup dashboard
    of a given capability to determine the level of value and risk it provides in
    the context of cloud.
  • Cloud Pattern Valuation – Robust metric
    driven analysis tool used to determine which cloud service and deployment
    models should be used for a solution.
  • Cloud Pattern Matching – Graphical tool
    to connect service and deployment models with business or technical capabilities.
  • Portfolio Analysis – A tool to plot cloud
    opportunities to a grid based on Business Priority, Value, Risk and Effort to
    aid in the roadmapping.
  • Cloud Opportunity Dashboard  – A dashboard that provides a complete
    rollup of the Cloud Valuation assessments into one sheet to support decision
    making.
  • Cloud Taxonomy –This taxonomy provides a
    way of rationalizing cloud specific cloud implementation decisions.
  • Cloud Risk Framework – A risk reference
    model that identifies the key aspects of cloud risk to be assessed.
  • Cloud Risk Method – Process for applying
    a risk classification to a potential cloud solution.
  • CSP Project Planning – Examples of a
    defined project engagement, with timelines, milestones, activities and
    deliverables.

A good example of a tool leveraged in CSP is The Capability Planning
Tool. It analyses Business and IT capabilities under seven areas that fall
under four assessment drivers: architectural fit, value, risk, and readiness:

  • Architectural
    Fit
    : Adoption and Complexity
  • Value:
    Cost and Strategic Alignment
  • Risk:
    Significance and Regulations, Standards, and Policies
  • Readiness:
    Organizational Readiness and Technical Readiness

For all capabilities, the EA will ask the customer for the enterprise’s
score in each topic area. For example, for the business capability, Claims
Management, the EA will ask for the capability’s level of adoption based on the
following criteria: 5-Enterprise-Proven, 4-Tested, 3-Industry-Proven,
2-Emerging, and 1-Not Available.

This assessment is intended to capture a range from 1 to 5 for each
topic area under these assessment drivers. The end result is a rolled-up
dashboard with the scores of architectural fit, value, risk, readiness, and an
overall score for each capability. The final results presented in the dashboard
will allow the EA to determine the high-priority capabilities with the
customer.

Mike The Architect Blog - Capability Planning Tool Worksheet
Mike The Architect Blog - Capability Planning Tool Dashboard

Conclusion

The Cloud Strategy & Planning (CSP)
guidance helps establish a common context for cloud computing among all
business and IT stakeholders. Furthermore, it allows companies to define an
actionable cloud opportunity plan for qualified & validated cloud
opportunities to be architected for a specific service and deployment model.

The CSP guidance has 3 phases and 7
activities which give an overall structure to the approach. These allow the
client to assess and identify the current maturity level of their competences,
to find out which of these are best suited for cloud migration, and to evaluate
and better understand the opportunities for cloud solutions in the
organization. This assessment will ultimately lead to a business transformation
roadmap that is aligned with the enterprise’s technology and business
objectives. 

A few key points:

  • Focus on Maximizing Business Value – Leverage a business top down
    process of analysis and refinement, describing business capabilities to matched cloud technologies is essential
  • Capability
    Driven
    – Respect both the business and IT dimensions of an organization
  • Balance
    Value and Risk
     – Identify cloud
    opportunities while also rationalizing the potential challenges
  • Leverage Industry Best Practices – Amplify value of proven methods, models
    and tools to reduce risk of a poorly planned and executed strategy.

Related articles

Technology Architecture Questions for Vendors
Challenge the Status Quo and Advance Business through Cloud Computing
TOGAF Templates