Mike Walker's Blog

Come see me present Why EA’s Must Drive Cloud Strategy and Planning at the Open Group Conference

For those that are attending the Open Group conference in San Francisco here in the next few weeks from now I wanted to let you know that I will be presenting. My presentation is within the Cloud Strategy and SOA Governance track entitled “Why EA’s Must Drive Cloud Strategy and Planning” .

If this is a topic of interest to you or your organization, please stop by. It would  be great to see you there and answer any questions you may have.

Additionally, if you are at the conference or in the San Francisco area and would like to get together please let me know.

 

More

• My Session and Others: http://www3.opengroup.org/events/timetable/628
• Conference Home Page: http://www3.opengroup.org/sanfrancisco2012 

 

Technorati Tags: Cloud,Strategy,Enterprise Architecture,EA,TOGAF,Open Group Conference,Open Group

Open Group Publishes its First Cloud and International SOA Standards

Today, The Open Group announced three new industry standards to enable businesses to effectively integrate elements of SOA and Cloud Computing into a solution or enterprise architecture. The new standards are:

• SOA Reference Architecture
• Service-Oriented Cloud Computing Infrastructure Framework
• Open Group Service Integration Maturity Model

 

SOA Reference Architecture

Provides a blueprint for creating and evaluating SOA solutions. With the release of the SOA RA Standard, enterprise architects now have a common language and approach for creating SOA solutions that meet different organizational needs, and bridge the gap between business and IT.

 

This specification presents an SOA RA, which provides guidelines and options for making architectural, design, and implementation decisions in the implementation of solutions. The goal of this SOA RA is to provide a blueprint for creating or evaluating architecture.

Additionally, it provides insights, patterns, and the building blocks for integrating fundamental elements of an SOA into a solution or enterprise architecture.

Informally, the aim of the SOA RA is to answer some of the key questions and issues encountered by architects, including but not restricted to common questions such as:

• What are the aspects, building blocks, and layers of an SOA that I need to consider in designing solutions, establishing enterprise architecture guidelines, or assessing an architecture based on service-oriented principles?
• What are the building blocks I need to include in each layer of my solution or standardize as part of a enterprise architecture?
• What are some of the key architectural decisions I need to make when designing a solution, or assessing an architecture that is based on service-oriented principles?
• How do I increase my chances of gaining benefit from using SOA by taking into account key layers and building blocks with which I may initially be unfamiliar as our company makes it journey through higher levels of maturity? One of the ways in which we can establish a baseline and move to higher levels of maturity is to use The Open Group Service Integration Maturity Model (OSIMM) [21].
• Which roles in a project would benefit from using these principles and guidelines?

The SOA RA is used as a blueprint and includes templates and guidelines for enterprise and solution architects as well as software engineering roles within the software development life-cycle. These facilitate and ultimately enable automation and streamlining the process of modeling and documenting the architectural layers, the capabilities and the Architecture Building Blocks (ABB) within them, options for layers and ABBs, mapping of products to the ABBs, and architectural and design decisions that contribute to the creation of an SOA. It is intended to support organizations adopting SOA, product vendors building SOA infrastructure components, integrators engaged in the building of SOA solutions, and standards bodies engaged in the specifications for SOA.

More: http://www.opengroup.org/soa/source-book/soa_refarch/intro.htm

 

Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework

Is the first Cloud standard from The Open Group, which outlines the concepts and architectural building blocks necessary for infrastructures to support SOA and Cloud initiatives.

Service-Oriented Cloud Computing Infrastructure (SOCCI) is the realization of this framework for the cloud. This document details the SOCCI elements, the synergies realized through the cohesive application of SOA and cloud-based principles, and the SOCCI Management Building Blocks. It expands upon the relationships between service-orientation and its application to various infrastructure components. Finally, the concepts outlined are explained in the context of a business scenario – Motor Cars in the Cloud.

Participants have specific requirements from the cloud computing infrastructure. We will be elaborating on these requirements. The relationship of the base roles (Consumer, Provider, and Developer) and composite role (Integrator) are described above.

More: http://www.opengroup.org/soa/source-book/socci/intro.htm

 

Open Group Service Integration Maturity Model

Delivers a common maturity model, which has now been ratified as an ISO and IEC International standard, for advancing the continuing adoption of SOA and Cloud Computing within and across businesses.

The Open Group SOA Integration Maturity Model (OSIMM) provides consultants and IT practitioners with a means to assess an organization’s Service Oriented Architecture (SOA) maturity level. It defines a process to create a roadmap for incremental adoption which maximizes business benefits at each stage along the way. The model consists of seven levels of maturity and seven dimensions of consideration that represent significant views of business and IT capabilities where the application of SOA principles is essential for the deployment of services. The OSIMM acts as a quantitative model to aid in assessment of current state and desired future state of SOA maturity.

 

More: http://www.opengroup.org/soa/source-book/osimmv2/intro.htm

 

More information

• Press Release - www3.opengroup.org/news/press/open-group-publishes-new-standards-soa-and-cloud
• SOA Reference Architecture PDF - https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12490
• Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework (SOCCI) PDF - https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12510
• OSIMM V2 PDF - https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12450

 

Technorati Tags: Enterprise Architecture,Solution Architecture,SOA,Cloud,Reference Architecture,Patterns,Open Group

Is TOGAF Bringing the “S” to BAIT with SABSA?

 

In my last post I wrote about the Open Group TOGAF and SABSA integration announcement. This shows both a real sense of partnership with leading industry bodies and it seems like a step in the right direction to advance the TOGAF method, models and tools with security and risk management content.

But does this published whitepaper on the integration of SABSA’s Risk and Security Management practices really add Security and Risk Management to TOGAF? On the surface,  there are quite a few gaps SABSA is filling in maturing and frankly, documenting and applying guidance to address big gapping holes in the existing TOGAF specification.

When I say “on the surface”, it means that this material is in the form of guidance only. It is not as an official part of the TOGAF specification. Treated as an extension or an overlay at this point shows extensibility of TOGAF but it can also present unneeded complexity in the framework. 

So, this brings us to the to the question, Is TOGAF Brining the “S” to BAIT with SABSA? Yes and no. It really depends on how you look at it. Technically, no. The BAIT architecture domain model hasn’t been revised with TOGAF 9.1 and there are no press releases or announcements to state a modification to the core architecture domains that TOGAF addresses. 

However, I believe this is a net positive add to TOGAF. In the form of delivery guidance is one step in the right direction and provides some other benefits such as:

• Rationalized - For existing SABSA practitioners it shows how to apply TOGAF and vice versa.
• Applied – Since this is in the form of delivery guidance it shows how to apply it and not just what it is within a specification. There is a challenge with no having enough in the specification, but there is a practical need to fill this gap and this is better than nothing.
• Intent – This shows real intent by The Open Group forum members to not let TOGAF get too stale with the additions linking of other practices.
• Unification - Instead of reinventing yet another standard, clear industry leadership is demonstrated by The Open Group to reduce complexity in the Enterprise Architecture space.
• Best of Breed –  Along with not reinventing a standard a best of breed addition was selected that has similar guiding principles and approaches that make this integration compatible.

 

Technorati Tags: Enterprise Architecture,Risk Management,Information Security,TOGAF,SABSA,The Open Group

Enterprise Architecture Certifications Distilled

Year after year I am finding that Enterprise Architecture certifications are becoming more important to architects. Back in 2007, I remember reading an article from Gene Leganza called, “Is EA Certification Important?”. In that article he stated that 65% of the people he had surveyed stated that EA certification is not important but he also noted that a significant minority stated they were including EA certification criteria in their hiring processes. 

Over the years, I have seen that minority rise significantly. First it started with software vendors and consultancies that required certifications for EA’s. Now we see certification requirements in job descriptions and RFP’s for vendors. The reason for this is very simple, trust. Companies want to make sure that architects have been validated by an independent body so they don’t have to go through that same rigorous process and focus on their business challenges.

The next year I found evidence that there was a shift as well. In a post, “Enterprises are Embracing Architecture Certifications” I discovered an article from IT Job Watch that stated that salaries went up by 21 percent with certifications. Surprisingly in the UK geography 80% companies require TOGAF certification.

While this is just one data point, you also see this on job descriptions on popular job boards.

However, when you look at the landscape of certifications it can be very confusing and even daunting to try to figure out which ones to take. Certifications take a substantial amount of time to study for, prepare and to actually take. This coupled with the impacts of todays economic climate of reduced IT budgets and education it so much more important to pick the right certifications.

To help reduce this confusion, I created the Enterprise Architecture Certification Reference Guide. Within it, I distill the EA certification domain within a framework that splits each certification into a logical areas.

 

Enterprise Architecture Certification Reference Guide

The Enterprise Architect Certification Reference Guide serves as an atlas to navigate the specific certifications for a Enterprise Architecture (EA). Other areas of architecture such as domain or solution architecture are within the corresponding Certification Reference Guides. The reference guide decomposes certifications into a framework that allows the EA to identify the certifications that are right for them. Starting with certifications that validate an EA’s competencies (experience and skills), then to certifications that derive from a specific business or industry set of concerns to the foundational certifications that enhance the skills of EA’s and will aid in the acquisition of competencies.

As shown above, the Enterprise Architect Certification Guide provides a framework to how to think about EA certifications.

Below is a description of each aspect:

• Competency Based Certifications – These certifications are focused at evaluating your experience to validate that you are indeed an architect. Much like many other certifications in the industry (e.g., PMP). These are much different to others that determine what you know instead of how you applied the knowledge.
• Industry / Specialized Certifications – Driven from a predetermined set of concerns such as the federal government or a specific industry is where these derive from. While these certifications are critical in that vertical, often times they do not transfer well across verticals given the difference in drivers and motivations of these very specific bodies of knowledge.
• Foundational Certifications – Provides the essential skills for EA’s. These certifications are different from the other two in the respect that they validate that you’re an architect while foundational certifications validate that you know a specific methods, models and/or tools. These certifications are essential to EA’s as they populate the EA’s toolbox. For example, without an overall enterprise architecture framework how would we be truly effective as EA’s?
• Applied – Divided into two primary areas, Academic and Vendor Tailored they either support a certification or provide a certification highly tailored. These are in a supporting function to Competency Based Certifications.
• Supporting Certifications and Learning's – These certifications make a well rounded enterprise architect. These are often referred to or leveraged in the day in the life of an EA.

 

 

Resources

Competency Based Certifications

• Open CA Site
• The Open Group Certified Architect Program Distilled
• Experiences taking the Open CA certification
• Conformance Requirements (Multi-Level)
• Sample Certification Packages
• Sample Certification Agreement
• How you can become Open CA certified and how your organization can become Open CA accredited
• Architect Certification Impacts Cloud

 

Industry / Specialized Certifications

• FEAF
• TEAF
• DODAF

 

Foundational Certifications

• TOGAF
• What you need to know about TOGAF 9.1
• IASA Foundation
• Zachman
• SEI Architecture & Trade Off Analysis
• Archimate
• CITS

 

Supporting – Academic

• Enterprise Architecture Goes To College, EA Becoming Academically Recognized and Offered [Updated]
• Penn State University
• Kent State University
• RMIT

Supporting – Applied and Tailored

• Accenture Master Technology Architect
• IBM
• Oracle
• Sun Enterprise Architect
• CISCO

 

 

Technorati Tags: Enterprise Architecture,Certification,Open CA,TOGAF,IASA,EA,Zachman,ArchiMate

What you need to know about TOGAF 9.1

On December 1st we see the first revised TOGAF 9 specification since its release in 2009. This brings TOGAF to version 9.1 with 450 changes that addressed 400 comments from EA practitioners. This release promises downward compatibility to the TOGAF 9 specification and certifications. 

While there are many changes, there are no material differences in the direction or features in this version but rather a refinement of the existing framework. 

I do think this was a great idea for the Open Group. With any standards body work where it is driven by many people and companies (in this case hundreds of member companies) there are sure to be a few inconsistencies or mistakes along the way. Just like with anything, such as book (revisions) or software (service packs) the Open Group is recognizing they need to be more agile in the delivery and not wait for a big drop in TOGAF 10. 

While have not re-read the TOGAF 9.1 specification end-to-end (and there is no need if you have done this with TOGAF 9), being a member of the TOGAF Architecture Forum I have seen the direct result of the improvements and advances being made to make the standard more applicable to Enterprise Architects and their daily architecture efforts along with the added consistency of a standard that is completely driven by it’s member companies. 

 

What’s New, Modified and Removed

Material that has been removed:

• Definitions of terms where usage by TOGAF is not distinctive from the common dictionary definition have been removed
• The Building Blocks example has been removed
• The Document Categorization Model has been removed
• The Evaluation Criteria and Guidelines have been removed from Part V, Chapter 42

Material that has been substantially revised:

• The Phase E and F descriptions have been reworked to match the level of detail in other phases
• The concepts of levels/iterations/partitions have been clarified and made consistent. This includes a reorganization of material in Part III, Chapter 19 and Chapter 20, and Part V, Chapter 40
• The "Objectives" sections of the phases have been reworked to focus on actual objectives rather than techniques or a list of steps
• The SOA chapter (Part III, Chapter 22) has been updated to describe the latest SOA Work Group output
• Additional introductory text on architectural styles has been added in Part III, Chapter 18

Areas where inconsistent use of terminology has been addressed:

• The usage of the terms "application" versus "system" has been reviewed and made consistent
• The uses of terminology for Transition Architecture/Roadmap/Implementation Strategy have been clarified and made consistent
• The possible artifacts (viewpoints) for each phase are now listed in the description of that phase, not just in Part IV, Chapter 35
• The terms "artefact" and "viewpoint" have been clarified and made consistent. This includes a restructuring of Part IV, Chapter 35
• Minor changes have been made to the Security Architecture chapter (Part III, Chapter 21) for consistency with the ADM
• Corrections have been made to metamodel diagrams
• Corrections have been applied to aspects of the metamodel. Part I: Introduction 35
• Duplicate text in several places has been replaced with an appropriate reference:

•  
  • Gap Analysis in Phases B, C, and D now references Par t III, Chapter 27
  • Requirements Management in several phases now references Par t II, Section 17.2.2 in the Requirements Management phase

• Some of the artifacts have been renamed to better reflect their usage:

•  
  • System/Data matrix becomes Application/Data matrix
  • Class diagram has been replaced with Conceptual Data diagram and Logical Data diagram
  • System/Organization matrix becomes Application/Organization matrix
  • Role/System matrix becomes Role/Application matrix
  • System/Function matrix becomes Application/Function matrix
  • Process/System Realization diagram becomes Process/Application Realization diagram
  • System Use-Case diagram becomes Application Use-Case diagram
  • System/Technology matrix becomes Application/Technology matrix

• The description of Architecture Principles now divides them into two types only - Enterprise and Architecture - whereas before IT Principles were called out separately. IT Principles are now seen as just part of Enterprise Principles
• The Stakeholder Map included in the Stakeholder Management chapter (Part III, Chapter 24) is now explicitly referred to as an example, the table has been highlighted to refer to Stakeholder Concerns, and the list of artifacts for each stakeholder updated
• The Business Scenarios chapter (Part III, Chapter 26) has been renamed to Business Scenarios and Business Goals to better reflect the contents of the chapter
• The relationship of the Enterprise Repository to the Architecture Repository is clarified in Part V, Chapter 41
• The chapter on Architecture Maturity Models (Part VII, Chapter 51) has been editorially revised for consistency and clarity

Certification

• The TOGAF 9 Certification for People Program has been designed to accommodate maintenance updates to the TOGAF 9 standard such as TOGAF 9.1 
• The two levels of certification remain as TOGAF 9 Foundation and TOGAF 9 Certified 
• Individuals who are currently certified in the TOGAF 9 People Certification program remain certified 
• The Conformance Requirements for TOGAF 9 Certification have been updated and will become mandatory on June 1, 2012 
• All Accredited TOGAF 9 Training Courses will be updated to the revised Conformance Requirements by June 1, 2012 
• In the period between December 1, 2011 and June 1, 2012 candidates can study either to the original Conformance Requirements or the revised Conformance Requirements 
• The examinations have been designed to accommodate both up to June 2013, which allows candidates up to twelve months after studying to take the exam 
• The reference text provided with the Open Book examinations will remain TOGAF 9 until June 1, 2012 and will then switch to TOGAF 9.1 after that date 

 

Resources

• TOGAF 9.1 Site - http://pubs.opengroup.org/architecture/togaf9-doc/arch/
• TOGAF 9.1 Summary Presentation - http://www.togaf.info/togafSlides91/TOGAF-V91-Extra-TOGAF91-Changes-Overview.pdf 
• TOGAF 9.1 Specification Download: http://www.opengroup.org/architecture/togaf91/downloads.htm

 

It’s Official, I’m a Open CA Level 3: Distinguished Chief Architect

As some of you may have noticed on my twitter feed, I have been activity doing research the Open CA certification. Through the research and it’s reputation, I decided that I would take it based on my findings. I am happy to announce that I passed my Level 3: Distinguished Chief / Lead Architect certification!

I have to say, what a great experience this was. Not because it was easy, it was actually quite a lot of work and it is a very serious certification that wasn’t easy at all. But rather, I was amazed by how professional the whole process was. The formality from the beginning to the end showed there was no variability in the process and no hint of any sort of subjectivity in the process. This is what an Enterprise Architecture certification must provide. Additionally, the certification board that interviewed me was top notch. I was humbled to be interviewed by such professionals with their level of experience and knowledge in EA and other fields.

A big thank you to the Open Group and the members of the board that interviewed me.

 

Some maybe wondering what is Open CA. How is it different from what people commonly think of from an EA certifications or the differences in Open CA and TOGAF certifications. The Open Group has two certification programs: TOGAF and Open CA (formerly ITAC). These two are very different certifications. They are for two different purposes. 

• TOGAF Certification – in simplest terms, TOGAF certification validates that you know the TOGAF specification to a great level of detail. This certification excludes validating that you are an architect. So by this rule, a non-architect that studies the TOGAF materials can be TOGAF certified. One can learn the TOGAF book and do a multiple choice computer based exam. If the exam is done in good standing, the architect is certified. TOGAF certification looks very much like most exam based certifications (e.g., PRINCE 2) certification for project managers.
• Open CA Certification – is primarily concerned with the competencies that an architect possesses. In other words, how an architect thinks through solving a set of broad highly impactful enterprise problems to realize business value. For Open CA certification, it is not needed to be TOGAF certified or even know the TOGAF framework , that is one of many validated frameworks. One must prove to be able to have done architectural work in real life situations for many years. Open CA certification is very much like PMI certification for project managers that require detailed documentation, letters verifying your experience and a set of interviews to validate what was documented.

 

It is extremely important to have the TOGAF certification as well as the Open CA. Both are important and both have roles. As I stated above, TOGAF certifies that you have the skills to know what are the architecture practices, methods, models, tools and mental models. However, Open CA certifies that you have the competencies to do architecture well by validating how you do architecture.

 

So the difference in my mind: TOGAF = Skills and ITAC = Competencies

 

There are approximately 2,500 Open CA at three levels combined and 7,200 TOGAF 9 certified architects in 50 countries around the world.

The Open CA certification is an international standard. There are three levels:

1. Certified IT Architect

2. Master Certified IT Architect

3. Distinguished Certified IT Architect

 

Level 1 is the easiest to get, level 3 the hardest.

 

To get Open CA certification, a certification package must be created by the applicant. This certification package must contain proof of the various Open CA conformance requirements, including signed documents letters from people you worked with. A level of quality control here is  that these reference letters can not come from a direct report of yours nor can it come from one of you direct line managers either.

After the certification package is applied, the architect is invited to visit a certification board. The architect must then present a case from his certification package to the certification board. The certification board will ask questions to the architect. And if all goes well, the architect can receive certification.

The requirements that lead to the certification package are not easy to conform to. Below are some resources to give you more information:

• Open CA Site
• Guide for Getting Started
• Certification Guide
• Sample Certification Packages
• List of recognized architecture methods can be found here

 

The Open CA certification is very hard to get, but it is a very valuable title to have as an architect.

Technorati Tags: Enteprise Architecture,Open CA,Open Group,TOGAF

Get the TOGAF 9 Template Artifacts and Deliverables for Free

Free Registration Required.

 

This is an example set of templates for TOGAF 9. It includes example artifacts for all catalogs, matrices and diagrams, and template deliverables.

http://ow.ly/5IS6T 

 

Example artifacts are as follows:

• Catalogs:
  • Application Architecture: Applications Portfolio Catalog, Interface Catalog
  • Business Architecture: Contract-Measure Catalog, Driver-Goal-Objective Catalog, Location Catalog, Organization-Actor Catalog, Process-Event-Control-Product Catalog, Role Catalog, Service-Function Catalog
  • Data Architecture: Data Entity-Data Component Catalog
  • Preliminary: Principles Catalog
  • Requirements: Requirements Catalog
  • Technology Architecture: Technology Portfolio Catalog, Technology Standards Catalog
• Core Diagrams:
  • Application Architecture: Application & User Location Diagram, Application Communication Diagram, System Use-Case Diagram
  • Architecture Vision: Solution Concept Diagram, Value Chain Diagram
  • Business Architecture: Business Footprint Diagram, Business Services and Information Diagram, Functional Decomposition Diagram, Product Lifecycle Diagram
  • Data Architecture: Class Diagram, Data Dissemination Diagram
  • Opportunities and Solutions: Benefits Diagram, Project Context Diagram
  • Technology Architecture: Environments & Location Diagram, Platform Decomposition Diagram
• Extension Diagrams:
  • Technology Architecture: Network Computing-Hardware Diagram, Processing Diagram
• Matrices:
  • Application Architecture: Application Interaction Matrix, Role-System Matrix, System-Function Matrix, System-Organization Matrix
  • Architecture Vision: Stakeholder Map Matrix
  • Business Architecture: Actor Role Matrix, Business Interaction Matrix
  • Data Architecture: Data Entity-Business Function Matrix, System-Data Matrix
  • Technology Architecture: System-Technology Matrix

Example deliverables are as follows:

• Preliminary Phase: Architecture Principles, Architecture Repository, Business Principles-Goals-Drivers, Organizational Model for Enterprise Architecture, Request for Architecture Work, Tailored Architecture Framework
• Phase A: Architecture Vision, Capability Assessment, Communications Plan, Statement of Architecture Work
• Phase B, C, D: Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap
• Phase E: Implementation and Migration Plan, Transition Architecture
• Phase F: Architecture Building Blocks, Architecture Contract with Business Users, Architecture Contract with Development Partners, Implementation Governance Model
• Phase G: Compliance Assessment, Solution Building Blocks
• Phase H: Architecture Change Request, Requirements Impact Assessment

These are provided in Microsoft Word format, Microsoft Powerpoint format, and Microsoft Excel format. The templates are provided in a zip file archive.

CIO's Must Make Enterprise Architecture a First Class Citizen

I am really liking the new string of articles and posts on The New World of Enterprise Architecture as I am calling it. It seems like the tone and the perceptions of Enterprise Architecture is slowly changing from pessimistic to optimistic on what EA should or could be. 

This brings me to this post, this is an important topic in that it get's to the heart of the "top down" organizational challenges.

You see that in recent series of blog posting from Dan Woods. In a more recent post called "Why CIOs Fail at Increasing Awareness Through Enterprise Architecture", he discusses that the CIO role must change. I mostly agree and would extend this a little bit more. Thanks for getting this out Dan, I think you hit the nail on the head.

Here are my general thoughts and observations based on my experience and industry observations in talking to CxO's around the world through Microsoft and out executive briefings:

• The CTO is referenced. I do not think that the CTO (at least how I define it) should be part of this equation. Just the CIO. The CTO is the Chief Technology Officer not the Chief Information Officer. If we look at these role names and what they do, they operate in different spheres. 
• I think we should give credit where credit is due. There is a transformation happening as we speak. I think this article could be spun in a much more positive light as we are seeing major players like Dell, USAA and others that have publicly talked about how they are business before technology all the way at the top levels of IT. Not only that, they are making investments in those areas. Again, noting wrong with the broader current state analysis. 
• Use just enough EA but don't over do it. EA just like anything is a very specific domain (e.g., ITIL = Operations or PMBOK = Project Management) Use the right tool for the right job, it doesn't mean however you can't leverage core principles or even elements of each to solve a problem.

In his post he gives a bit of a current state of the CIO and CTO. I think it relatively accurate with the outside few of CIO's that are more advanced than others. Ultimately it's representative of the industry. 

While it seems strange, most CIOs and CTOs (which I refer to collectively as CITOs) live in a state of limited awareness out of fear. CITOs are more comfortable running operations, evaluating technology, and developing new solutions than they are attempting to understand how and why the businesses use the systems they create. CITOs lack the temperament for the fuzzy world of business processes, and also lack the skills. If CITOs do start poking around, asking questions, developing metrics about how a business process is run, they will most likely be greeted by, “Why don’t you go do your job instead of measuring how I do mine?”

 

I think his assessment is pretty good but I think we can distill some more out of it and add a few more characteristics of the CIO:

1. Mode of Operation from Reactive to Proactive - This is the fundamental behavior in IT that has to change. 
2. Move from Order Takers to Collaborators - CIO's should help the business in a very collabrative manner not just take orders from them.
3. Run IT as a Business - There is a lot to learn here and a tremendous opportunity if more CIO's looked at IT as a Business Unit. As eluded to by Dave, a business not only creates new products and services but it also has to optimized it portfolio of products as well. And while CIO's do embark on modernization or optimization projects, it is usually a surface level technology optimization and not a true business optimization effort (e.g., desktop upgrades shifts to a business solution centric capability upgrade that may or may not involve a desktop upgrade, it could be mobility is the key.)
4. Make EA a First Class Citizen - Right now it is getting close, but not there yet. The EA charter is to help in the key areas of concern. Don't just say you are doing EA, institutionalize it!

 

For all this to occur there usually needs to be some catalyst. I come from the Financial Services space so I know this well. While there isn't a specific EA regulation like there is in the Public Sector / Government there is however, a strong lean towards EA. So you see very strong ties to EA as a result.

I agree with Dan's assessment that something has to happen (i.e, a crisis) but I think there are other entry points as well. Here are my thoughts:

1. Regulation - If there is significant risk and deemed to be regulatory this change will happen fast and will up level a industry at a time to a capability level.
2. Industry Tipping Point -Momentum in the industry makes this a forgone conclusion that this is what needs to happen. Global mind share is acquired.  
3. Viewed as a TRUE Competitive Differentiator - Right now this isn't the case broadly, but some companies are getting it. When this is made much more obvious this could be a catalyst for change as well.
4. Legal Implications - I always say, once someone is sued or put on the front page of the Wall Street Journal change happens pretty quick. I think this is true here as well. 

I do not see any evidence that IT will magically come up with this either by inwardly looking at itself nor comparing to the failures in IT overall. IT has already had an extremely poor track record with little broad and pervasive movement in this space.

But at some point, something really bad or really good happens. In a crisis, politics can get set aside as everyone takes a deep breath and focuses on how to make the business survive. In good times, a similar thing can happen in which the glow of success makes everyone feel secure. 

I also fully agree with Dan's statement shown below, as I stated above, that CIO's must make Enterprise Architecture a first class citizen.

What can we do about this?” CITOs should answer the call by suggesting the application of an established enterprise architecture methods. One of them is TOGAF, developed by The Open Group,  a consortium of IT users and suppliers that develops standards facilitating Boundaryless Information Flow™.

 

I wouldn't necessarily make everyone use an architecture method as it's not right for all problems. However, can we get people to think more like architects, yes! Can we get people to understand why we need architecture, yes! Can we get more people to appreciate the methods, activities, deliverables and key outcomes EA's wish to achieve, yes!

So with the comments around TOGAF, it's a starting point.

Use TOGAF to:

1. Get a common vocabulary within the enterprise
2. Obtain an understanding of how deliverables / documents achieve business outcomes
3. Level set on why we do specific methods
4. Think business first
5. Appreciate the rigor and science involved in Enterprise Architecture
6. Establish and leverage at multiple levels practices that scale to most problem areas like: Trade-Off Analysis, Risk Management and Transformation

So for me, I think Dan is right and what is shows it there is a great deal of opportunities that the CIO can leverage from the EA' by making them a first class citizen. They can also gain insights by shifting a portion of the way they think to be more architecturally grounded and not just technology.

More at Source: http://blogs.forbes.com/ciocentral/2011/06/23/why-cios-fail-at-increasing-awareness-through-enterprise-architecture/ 

 

Clarifying Alignment of Frameworks for Business Benefit

Most organizations employ multiple frameworks and standards for implementing and controlling technology. Here are some publications that map COBIT to other sources of guidance. While this is slightly out of date in terms of TOGAF it is still an interesting read to see how these frameworks relate.

COBIT Mapping Overview of International IT Guidance 2nd Edition

This document can be used to align guidance supporting IT governance, especially regarding IT control and IT security guidance in relationship to COBIT. It lists over a dozen international standards/guidance, and for each one provides a classification, a short overview of the contents and the business driver for implementing the guidance, and the risks of noncompliance. Included are:

• COBIT
• COSO
• ITIL
• ISO/IEC 17799:2005
• FIPS Pub 200
• ISO/IEC TR13335
• ISO/IEC 15408 2005/Common Criteria/ITSEC
• PRINCE2
• PMBOK
• TickIT
• CMMI
• TOGAF 8.1
• IT Baseline Protection Manual
• NIST 800-14.

Aligning COBIT 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefit

IT best practices should be aligned to business requirements and processes. Organizations often use multiple frameworks to inform how to achieve this. This management briefing is the result of a joint study initiated by the UK's Office of Government Commerce and the IT Governance Institute. It was first published in November 2005, and was updated in August 2008 to reflect the latest versions of three sets of guidance:

• ITIL V3-Published by the UK government to provide a best practice framework for IT service management
• COBIT 4.1-Published by ITGI and positioned as a high-level governance and control framework over IT processes
• ISO/IEC 27002:2005-Published by the International Organization for Standardization (ISO) and International Electro technical Commission (IEC) a to provide a framework of a standard for information security management

The appendices provide mappings:

• COBIT to sections of ITIL and ISO/IEC 27002
• ITIL key topics to COBIT
• ISO/IEC 27002 classifications to COBIT

 

Source: http://www.sox-online.com/cobit_mapping.html

TM Forum Frameworx and TOGAF Alignment

Recently launched at the Open Group meeting in London last week a venture between The Open Group and the TM Forum produced a 110 page report on how their two frameworks (TOGAF and Frameworx) align and where they extend each other. This report is a very deep and compressive with a quick reference guide.

I really like seeing this work. This is exactly what the enterprise architecture industry needs, the reduction of confusion and complexity between frameworks that have specific drivers vs. general purpose frameworks such as TOGAF.

Further evidence of this, I have been in western Europe for two weeks talking to some top Enterprise Architects in very large enterprises. I still get the questions around what is the difference between TOGAF and […X…]. Given this over whelming amount of confusion I hope these resources continue to be developed. For example, I would like the TOGAF 8 to ITIL 2 article to be updated to the latest versions.

In the report, it does a really good job of positioning TOGAF as the framework it intends to be, a general purpose framework. With a general purpose framework it is important to understand that it is meant to address a broad and vast amount of needs, to do so it needs to be generic and extensible so customers and services providers can add their specific business driven execution model on top. The report really demonstrates that modularity, extensibility and flexibility of their framework without jeopardizing the integrity of the core.

Below are two models that show these relationships.

 

 

 

Andrew Josey has put together such a great list of synergies that it would be incredibly redundant for me to regenerate these already great points.

Below is the summary of the identified synergies:

1. Immediate synergies have been identified between the TOGAF Architecture Development Method (ADM) phases Preliminary, A, B, C and the Common Systems Architecture of the Enterprise Continuum. This document addresses the TOGAF ADM phases from Preliminary to Phase C. The synergies between business services (formerly known as NGOSS contracts) and the Common Systems Architecture will be dealt with in a separate document.
2. TOGAF^® provides an Architecture Repository structure that can smoothly accommodate the mapping of TM Forum assets; this feature can be leveraged to identify and derive the added value of the content.
3. TM Forum assets can be classified as either Industry Architectures or Common Systems Architecture in (TOGAF^®) Enterprise Continuum language. TOGAF^® provides a widely accepted methodology to leverage these architectures into the development of enterprise architecture.
4. Professionals that use TM Forum assets will find templates and guidelines in TOGAF^® that facilitate the transformation of such TM Forum assets into deliverables for a specific project/program.
5. TOGAF concepts as defined in the TOGAF^® Architecture Content Framework provide clear definitions as to what artifacts from TM Forum assets have to be developed in order to be consistent and comprehensive with an architecture construct.

 

Resources

1. Publication - http://www.opengroup.org/bookstore/catalog/w114.htm

 

Technorati Tags: TOGAF,Open Group,Standards,Enterprise Architecture,EA Frameworks,eTOM,TM Forum