Mike The Architect

The Business Model Canvas: Know Thy Business

As Enterprise Architects we drive to maximize value in our companies. With most EA teams residing within an IT area under a CIO we can find ourselves bogged down by the technology weighing down on decisions. The challenge with that is one of context. Without understanding “Why” we are solving a problem will most certainly inhibit the value in which is achieved.

So the question is, do we really know our business before we make architecture decisions? What tools do we use or don’t use to understand the business model?

I was happy to see Alexander Osterwalder  publish on the Harvard Business Review blog a post titled, “A Better Way to Think About Your Business Model”.  Certainly take a look at this. His post provides some high-level information on why it’s important to use the model. If you find value in the model as I do, you will want to pick up his book, Business Model Generation. Personally I like the hard copy best given it’s so visual. There is also an iPad app that you can get that works really well too. You can find it in the Apple App Store here: https://itunes.apple.com/us/app/business-model-toolbox/id431605371?mt=8 

As I eluded to above, I have found a lot of value in this tool. It is one that I've been using for quite some time now. It’s a brilliant model that helps you dissect what your business is. The data itself isn’t rocket science. It’s the conversation that it triggers which drives the value. I often apply this in workshop like sessions rather than one off data collecting exercises.

 

 

WARNING: While it can allude to, the Business Model Canvas does not tell you why your business has been built in the fashion it has. This is within strategy oriented methods and models.

The business model canvas can really help you to understand your business. What is nice about it is that the questions can be applied at multiple levels. You can apply it at a corporate level or apply it to a business unit.

As an example of this, I applied it to an already established enterprise architecture organization. I used the model to assess the organization on its “health”. Asking those business oriented questions forces us to think as if we were a business unit, and that’s not a bad thing. The results were quite amazing because it got the right level of conversation and thinking going to evolve the overall value proposition.

 

About the Business Model Canvas

If your not familiar with the Business Model Canvas below is a two minute overview of the Business Model Canvas, a tool for visionaries, game changers, and challengers. The business model canvas — as opposed to the traditional, intricate business plan — helps organizations conduct structured, tangible, and strategic conversations around new businesses or existing ones. Leading global companies like GE, P&G, and Nestlé use the canvas to manage strategy or create new growth engines, while start-ups use it in their search for the right business model. The canvas's main objective is to help companies move beyond product-centric thinking and towards business model thinking.

 

 

Find out more at http://www.businessmodelgeneration.com

EA Practitioners Have Significant Influence on $1.1 Trillion in Enterprise IT Spend

Gartner just released a report entitled, "EA Practitioners Have Significant Influence on $1.1 Trillion in Enterprise IT Spend” that strongly links to their Business Outcome Driven Enterprise Architecture.  This is interesting article because it’s shows the latest thinking from real EA practitioners with some real good stats on where we are at from an industry perspective. 

What is also clear is that EA is now positioned to do what we have wanted to do for years, drive business results not just technology decisions. This is a big opportunity for us and it is now our opportunity to lose.

 

EA Practitioners Have Significant Influence on $1.1 Trillion in Enterprise IT Spend

Fifty percent of enterprise architecture (EA) practitioners have a significant impact on enterprise IT budget activities and decisions, according to a recent survey by Gartner, Inc. A July 2012 Gartner survey of EA practitioners found that half of EA practitioners have an influence over their organization's IT budget allocation that is either "final decision maker" or "great deal of influence."

Based on the EA survey results from Gartner events in North America and Europe, analysts estimate that EA practitioners have a "final decision-making" influence on $331 billion in worldwide enterprise IT spend and a "great deal of influence" on $774 billion in worldwide enterprise IT spending. Overall, EA practitioners have an influence that is either "final decision maker" or "great deal of influence" on $1.1 trillion in worldwide enterprise IT spending.

"Overwhelmingly we find EA practitioners focused on delivering on business value and strategic transformation," said Philip Allega, managing vice president at Gartner. "Gone are the days of just 'doing EA' with little value or impact. Sixty-eight percent of organizations surveyed stated that they are focusing their EA program on aligning business and IT strategies, delivering strategic business and IT value, or enabling major business transformation."

Gartner is leading the way in defining and mastering a radical new approach to EA, which is business outcome-driven EA. Leading EA practitioners are focused on creating diagnostic deliverables to help business and IT leaders respond to business and technology disruptions.

"This new generation of EA practitioners offers technology and service providers (TSPs) with an opportunity as well as a threat," said Mr. Allega. "Technology and service providers should develop targeted marketing to this new generation of EA practitioner as they have a significant influence on their organization buying decisions. Those that fail to understand the priorities, strategic focus and impact of EA practitioners will jeopardize their ability to sell into an organization."

Gartner has identified the impact of EA trends on IT purchasing decisions, and has the following advice and recommendations to help TSPs target this audience more effectively:

In organizations supporting EA as strategic, and as collaborative between business leaders and IT, TSPs will increasingly find EA practitioners influencing IT spend.

EA practitioners have a high degree of influence over emerging technology purchases, with 52 percent of the EA practitioners surveyed reporting directly to a CIO or CTO. They are also "very involved" in integration consulting services (64 percent) and business applications (52 percent). As EA practitioners continue to focus on integrating and aligning with business priorities and actively working with business leaders, their degree of influence on business intelligence tools, workplace tools and business applications will likely increase as well.

Organizations starting, restarting or renewing their EA efforts present an opportunity for providers to market to and influence a new generation of EA practitioners.

The survey revealed that 77 percent of respondents were either restarting or renewing EA efforts (18 percent), initiating EA for the first time (34 percent) or taking EA efforts to the next level (25 percent). In organizations starting EA for the first time, EA practitioners have a significant influence on IT budget decisions, but significantly less have decision-making authority. These new and restarting organizations present an opportunity for TSPs to target a new generation of EA practitioners.

As organizations become more mature in supporting EA, they will have a greater degree of influence on IT budget allocations to products and services.

Many organizations begin their EA journey by focusing inside the IT organization on system consolidation, standardization and cost management. As they mature, this evolves into looking more closely at the "alignment" between the business strategy and IT strategy. From here the EA program evolves further to become "business outcome-oriented," such that in a mature EA program, other areas of decision making are guided and influenced by business outcome-driven EA.

 

More Information

Additional information is available in the Gartner report, "EA Practitioners Have Significant Influence on $1.1 Trillion in Enterprise IT Spend”. The report is available on Gartner's website at http://www.gartner.com/resId=2286216.

Come See Mike Walker Speak on the EA Industry Expert Panel and Present at the Troux Conference 2013

The Troux Worldwide Conference is returning to Austin, Texas on March 19-20, 2013. If you are a Troux customer, partner, or actively involved in Enterprise Architecture (EA) or Enterprise Portfolio Management (EPM), this is your opportunity to enjoy peer networking and joint learning with a focus on delivering rapid results with Troux EPM solutions.

I'm flattered and feel very fortunate to be invited back to speak on the EA Industry Expert Panel for a third year in a row! This is certainly an honor and I thank Troux for the opportunity to be invited back to this exclusive event each year. I especially am humbled to be surrounded by a great line up of speakers and EA practitioners. 

It should be a great event!

If there are folks that are the conference or in the Austin area that want to meet up to discuss EA please let me know either through the comments on this post or through Twitter. 

 You can see me in two sessions:

1. Presentation - Highly Impactful EA Organizations Make Value Driven Decisions
2. EA Industry Expert Panel - Success in the Connected Enterprise

 

Below I have provided the descriptions of each:

Highly Impactful EA Organizations Make Value Driven Decisions
Enterprise Architects are faced with a rapidly changing business climate, competitive pressures and a shifting technology landscape that is forcing the enterprise to evolve. With this acceleration of change in the market it requires faster decisions that are well informed to maximize value. Enterprise Architects are at the tip of the spear to enable this change but need the tools.

In this session I will explore one of the proven practices that I have found from highly impactful Enterprise Architecture (EA) organizations, namely enterprise portfolios. Enterprise portfolios extend past the traditional project and program discipline to cover all aspects of the enterprise. Moving from disconnected, static and context-less pieces of data to a governed portfolio of enterprise knowledge that can maximize value and mitigate risk to our businesses.

Success in the Connected Enterprise

Success in the connected enterprise requires that executives understand the cause-effect relationships that exist across their organization. They must know what can and should change, when to change it, and where to take risks, all while avoiding unintended consequences. Transforming people, product and processes is difficult, but it is even harder without having access to detailed and reliable knowledge about how the parts of their organizations fit together, operate and evolve. In this session our panelists will share their personal insights, and answer your questions, on how they use various portfolio concepts to navigate and guide critical decision-making in their organizations

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

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):

• Zachman 
• SABSA 
• Business Technology Management (BTM) 
• DODAF
• COBIT - Part 1 | Part 2
• TMForum Framworx 
• C4ISR Architecture Framework
• CORBA 
• Enterprise Architecture Planning (EAP) 
• Federal Enterprise Architecture: Practical Guide - 
• FEAF 
• ISO/IEC TR 14252 (IEEE Std 1003.0) 
• NCR Enterprise Architecture Framework 
• ISO RM-ODP
• SPIRIT Platform Blueprint Issue 3.0
• TAFIM 
• TEAF 

 

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

 

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.

Culture Mapping Tool

Dave Gray posted on his blog that he has created a tool to help understand corporate cultures. This looks very interesting… I could see lots of uses for this tool as an Enterprise Architect. The typical stakeholder management only gets you so far, this takes it to the next level if the tool is effective. 

The collaborative effort between Dave Gray,  Alex Osterwalder, Alan Smith, and Chris Finlay has yielded a prototype and the graphic below:

 

In his words:

The culture mapping tool was so useful that I have long thought it would make an excellent tool for any company that’s dealing with a difficult transformation that will require rethinking, re-imagining or simply shifting the company culture.

 

More Information and developments

• Culture Map Blog
• Subscribe to get updates on the Culture Mapping project

 

TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex

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

 

A few 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. 

Open Group Newport Beach Conference Day Two Keynote Highlights

Keynote: Big Data and the Cloud – We Better Get it Right

Wow, what a great way to kick off the second day!  I found that this presentation had so much useful information for enterprise architects who want to build cloud based solutions. It was less about telling the audience the specifics but rather teaching them how to fish.

For those that read my blog it may not be a big secret that Mary Ann and I share the same concerns when it comes to cloud risk management.

She talks about the notion of Security 2.0. Mary Ann described Security 2.0 as the evolution of security where it shifts from being a reactive infrastructure oriented response to a business oriented risk management based approach. I couldn’t agree more and I have evangelized this heavily in the Cloud Strategy and Planning Framework I built where the notion of Value and Risk is core to understand before making investments into the cloud (Understanding Which Investments Should go to the Cloud, Cloud Strategy Begins with Value and Balances Risk ).

“Information is the life blood of your organization”

This is a key quote that I think is often overlooked but it is so important. We also see similar principle statements of “data is a strategic asset” but do we really treat data that way? I think this session highlights that there is a lot more opportunity for us to address that aspect.

The session covered two high hitting areas:

1. Current State of Security and Cloud
2. Addressing Security and Cloud

 

Current State of Security and Cloud

The message here is that the climate is really changing. Mary Ann said that:

• The business is changing – There are a number of forces on the business that are driving security
• Explosion of data – The rate of data that is consumed has exploded
• Real-time decisions – Consumers and business customers are expecting decisions and data in real-time.

The two slides shown drive this point home.

The first slide talks about the market research that HP done with their customers and generated some really interesting statistics. 

The second slide goes into the specific concerns that manifest from executives. 

As a result of all this new data, increased access to it and the seemingly lose control over it there has been an increase of regulation and compliance. But since what we know as the traditional notion of a corporate fortress is no more, we have a somewhat different model with new methods we need to support. 

Addressing Security and Cloud

The second major area of the presentation moved right into how to think about addressing security concerns in the cloud.

The key message here was that one security solution isn’t enough for cloud. There is a multifaceted approach. I agree with her on this. I often see architects and other roles try to address security by through infrastructure at the problem. However, with the cloud that all changes and we lose control of the things we could walk down the hall for.

Two slides I think will be useful to many architects are overlaying risk and security onto the NIST defined Cloud Service and Deployment Models:

Cloud Service Models & Security

Cloud Deployment Models & Security

While Mary Ann talked about their methodology at a high-level I don’t think she had to necessarily go into the details. The key point is that HP / Mary Ann gets the fact that having a repeatable and predictable method is a key part to the notion of Security 2.0.

Below is the HP ATOM methodology

Great job Mary Ann! I really enjoyed the presentation. 

 

Open Group Newport Beach Conference 2013 - Big Data Panel

Continuing on the theme of Big Data, the Open Group held a panel on that topic with some of the keynote speakers along with other industry experts on this complex topic.

The topics included:

• Big Data and the EA Perspective
• Lessons learned
• Big Data’s relationship with the Cloud
• Mobility
• Security

 Below are the key insights that resonated with me.

Big Data and the EA Perspective

• Define what is useful data
• Institute a data life cycle through your governance practices
• Focus on what data is going to create business value
• Big data platforms were not built with data security in mind (example: Hadoop – access control mechanism not there.. Still needs third party controls)

 

Lessons learned

• Not all data is created equally
• Once you classify, then you can do something with it

 

Big Data & Cloud

• Need to figure out information, service level agreements and risk analysis 
• Sometime the risk analysis points to private cloud
• If you are thinking about moving big chunks of data around the enterprise, then cloud may not be an option. Figure out real-time data, Hadoop solutions, ETL or Data Warehousing.

 

Mobility & Development

• Developers are now developing  for mobile first or at a minimum mobile compatible
• It is important to address security in the mobile tier. How important is to make data avail to mobile device
• In general, if consumers have access to it on their desktop, they will want it on their mobile

 

Value of Big Data

NASA is using Big Data in several small projects, mostly in the visualization realm.

Example: Write an app to use NASA data to allow a farmer to have an iOS app to determine what they should grow. The team that worked on it realize that great satellite data wasn’t enough. They decide to build the “mash-up” of data through other sources. The mash-up was vital to getting an accurate view.