TOGAF Demystification Series: The Truth behind the TOGAF Standard Creation

I've only heard this one a few times but since this myth was recently referenced in one of the comments of the post,  "TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex" I thought it would be good to elevate it up to a post in case there was similar misconceptions out there.

To set the stage, the basis for this myth is that the creation of the TOGAF standard is done so by an elite and exclusive group of individuals in the EA community the jet set around the world to sunny tropical vacation destinations all the while eating all the free bagels and coffee one can consume.

That sounds like a lot of fun. Sign me up!

It's too bad this isn't real. 

So let's break this apart the myth into three digestible parts:

1. Set of Elite Individuals Driving the Standard
2. TOGAF Excludes Industry Developments and Research
3. The Standard is Developed in Leisurely Tropical Destinations

 

#1 – Set of Elite of Individuals Driving the Standard

This is by far the easiest one to dispel.  What you will find from the Open Group charter is that this concept goes against the grain of the core principles of the Open Group. This not only applies to  TOGAF but all of the standards that the Open Group creates.  You can find that this  dates all the way back to the UNIX days.  The process is open to any person employed by a member company can participate with no zero discrimination on any sort of politics, company status or individual status.

You can find this  statement on the Open Group's public facing website describing the process:

All member organizations of the Open Group are entitled to participate in one or more of The Open Group Forums — vendor-neutral environments where members share knowledge and resources, and collaborate on developing open IT standards and certifications. Covering a range of technical, business, legal and regulatory issues, each Open Group Forum addresses a specific functional area, and is fully supported by The Open Group’s resources.

Source: http://www.opengroup.org/getinvolved?tab=2 

The Open Group Forums and Work Groups are governed by the Open Group Standards Process which is governed by the following principles:

• Openness - Standards are developed in an open process.
• Consensus - Standards are based upon the consensus of the parties involved.
• Timely and Deterministic Process - Standards are developed using a deterministic process that delivers standards in a predictable and timely manner.
• Public Availability of Published Standards - Standards once published are made publicly available.
• No Legal Impediment to Implementation or Adoption - There must be no legal impediment to implementation or adoption of an Open Group Standard.
• Confidentiality - Material is kept confidential until published by The Open Group.

You can see evidence from my story referenced in the post  "TOGAF Demystification Series: TOGAF Sucks, Incomplete and Overly Complex" where I was able to come into the forum as a newcomer to the Architecture Forum and was able to effect change. I didn't have to be part of a ficticuiuos "good old club".

#2 - TOGAF Excludes Industry Developments and Research

The Open Group works just like most standards bodies do (that I know of). The standard is driven by it's members. The Open Group is an administrative funtion that helps enables its members rather than creating the standard. From my own experiences, I contrast this to my time in the financial services industry. I have participated in the following below and had indirect interaction with more:

• IFX
• SWIFT
• ACORD
• FSTC
• MBA 
• and many others

Each one of these standards bodies operate in a similar way as the Open Group. It is incumbent upon the members to bring the latest developments back to the forum to be vetted by the industry before getting published. There isn't a R&D arm that goes out and discovers what the standard should be and go and publish. The role of the standards body to to create to forum in which these experts in the industry can distill proven practices and not fads and emerging trends.

Why is this important to do it this way? It think it all boils down to the following attributes:

• Trustworthy – A standard you know has been vetted by your peers in the industry
• Credible – Give it was developed by your peers, there is a very high degree of it is based on real world deployments and lessons learned. 
• Foundational – This isn't the latest and greatest but rather the foundational proven practices in the industry.
• Low Risk – Given all the above factors this results in a lower risk of just going out to the market and pulling the trend of the year off the shelf and running with it. Given that these are proven practices, actually implemented with success it lowers your risk.  

Personally, this is what I want form a standards body. I want the standards body (in this case TOGAF)   to tell me what is the most vetted method and framework that I can use as a base for my arhiecture efforts, then I can apply the other emerging trends or other not so mainstream ideals to my company. This manages my risk exposure to my company.

If the standards body did the reverse and adopted all the latest ideas and trends I would imagine that there would be a great deal of redundancy, conflicts and lack of guidance on how to apply as a result. I'm personally not interested in that scenario. 

#3 - The Standard is Developed in Leisurely Tropical Destinations

This one isn't a very well informed aspect of this myth. I can tell you that I haven't been a fan of the some of the destinations picked and very few of these have actually been at a beach. 

This comes from a very specific comment below:

One does not need to join the forum and participate at meetings in sunny places in order to contribute to the EA field. In fact it should be the other way around. 

NOTE: I don't have full insight to the specific policies, procedures and overall plans that the conference planners have with regards to this specific myth. I will share with you what I do know of the process. I would imagine it's pretty close but if the Open Group has any further clarifications I welcome them as a revision to this post. 

I don't think there is a simple one answer for selection of destination or why the why are the member meetings are the way they are. There are a two core drivers you I think you have to understand about the member meetings (TOGAF development in the Architecture Forum) to really answer the question. Those are:

• Multi-Purpose Events – The events where the Architecture forum meets are multi-purposed in nature. They hold the practitioner conference, certification, forum and workgroup activities.
• Maximize Value for Customers – By linking the development of TOGAF to the practitioner conference it serves as a way to consolidate travel, foster networking, collaboration and increase the overall in take knowledge through the conference materials and presenters. 

Given these two drivers and let's say the myth is true (it's not) then this would be no different than any other mainstream conference. Looking at both pure technology, analyst and industry wide all of which go to resorts, beaches or tourist destinations. But I haven't seen one Open Group conference in Vegas yet. I can't count the number of times I've been to a standards meeting in Vegas.

So to be factual I pulled the conference locations and bolded the tourist detonations (that I would consider) . It's interesting that there isn't too many beaches listed:

List of 2013 Open Group conferences: Newport Beach, Riyadh, Saudi Arabia, Abu Dhabi, UAE, Mumbai, India, New Delhi, India, Sydney, Philadelphia, London

List of 2012 Open Group conferences: Barcelona, Washington DC, Sao Paulo, Brazil, Dubai, UAE, Cannes, France, San Francisco

Now you could contrast that with other conferences and standards setting meetings as well for example the insurance industry standard ACORD events where they too combine conference with standards meetings. 

Conclusion

Again with this post I want to have a fact based conversation about this topic. Like many others I think this is a perception issue. At first glance, this may seem true (or at some parts of this myth) but if we take a closer look I think you will see it as I do that these are just myths. 

I do think there is an opportunity for the Open Group to do as I am doing, proactively dispel these myths by publishing and sharing these views (if they agree w/ my views as I'm not sponsored by the Open Group to write any of this content) with the architecture community. It could be a learning series, a set of FAQs or even going out to online forums like Twitter and LinkedIn to address some of these concerns.  

Again, I hope this helps and if you want to contribute to the conversation I welcome you to join in on the comments on this post. 

Advertisements

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

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 Artifacts – TOGAF 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:

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

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.

 

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.

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.

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

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.

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

TOGAF Templates

Possibly one of the most common questions I get with regards to TOGAF is finding a good sample set of templates. Luckily the Open Group has a set that you can download that is quite extensive. Personally they aren’t the prettiest to look at but it will most certainly be an accelerant to leveraging TOGAF.

See below for the links:

• Templates Part 1 – https://www2.opengroup.org/ogsys/catalog/I092
• Templates Part 2 – https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=i093

Below you will find a listing of some of the templates included.

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

 

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

 

TOGAF a Registered Trademark and Surpasses 15k Certifications



Interesting news from the Open Group in regards to their TOGAF® enterprise architecture framework standard.

The Open Group just hit two major milestones for the architecture standard:

1. The Open Group has announced via its blog that TOGAF® was recently granted registered trademark status.
2. The TOGAF standard has now surpassed 15,000 certifications worldwide.

In the words of the Open Group this means:

Both of these achievements highlight not only the global recognition that TOGAF® has achieved as an framework for creating enterprise architectures and for helping IT professionals distinguish their skill sets, but the need companies have for finding more efficient ways of operating and saving money.

MEGA annonces TOGAF and Business Architecture Offerings

Over the past few weeks MEGA an enterprise architecture (EA) tools provider, has recently announced  MEGA for the TOGAF framework and Business architecture solutions. I wanted to raise awareness of this update as a news item rather than an endorsement of the product. 

MEGA promises users that they can choose to begin an EA project using MEGA for TOGAF, then move seamlessly to a wider implementation using MEGA Process (BPMN Edition) and MEGA Architecture. It seems as if these announcements are aligning business architecture with the technology/solution architecture centric TOGAF. 

MEGA says they will aid TOGAF practitioners in these ways:

• Ensure EA project success by following the comprehensive Architecture Development Method (ADM).
• Facilitate project communication to all stakeholders with the collaborative development of TOGAF 9 deliverables.
• Customize the implementation of TOGAF and ensure all projects deliverables are aligned.
• Build current and future state transition architectures and compare them.
• Identify, document, and publish technical reference models.

MEGA also communicates the value proposition to business architects as well:

• assess and streamline major investments
• improve customer information management
• consolidate post-merger, post-acquisition business units and product lines
• incorporate outsourced and partner solutions
• conform to compliance and audit requirements

Establishing an Architecture Review Board

In my last post I talked about the definition of an Architecture Review Board (ARB), let’s talk now about what it means to create one. As we talked about in the last post, establishing an Architecture Review Board (ARB) is the best way to facilitate how IT decisions are made across the enterprise. Eliminating the behavior of making architectural discussions in a vacuum and providing visibility to how and why IT decisions are made. If done right, this should result in proactive decision making and raising the education across the enterprise on architecture trade-off analysis.

Keep in mind that establishing an ARB is often times a challenging feat. Introducing this function will effect the core of your Software Development Life Cycle’s (SDLC). This has the potential of touching everyone in the organization, so it is important to get it right.

If an ARB is new to you and makes sense to your organization there are some preliminary activities you are going to want to do in the beginning. Just like with most things in the architecture world you will have to sell, sell, sell…

It is very important that one of the first things you do is to ensure that your approach is bought into by the executive leadership team such as VP’s, CTO’s and CIO’s. Do this early and continue to engage all through the process. Their buy-in will ensure that your ARB get’s top down support.

Establishing support from the top isn’t the only support you will need. Gaining the support of the architecture community within your organization is vital. However, to get things rolling in the right direction you will need to establish the accountabilities and the process frameworks that is fully endorsed by your CIO.

Below are the general steps that can be used to create an ARB:

While there are many activities listed in the steps above, there is further decomposition needed. Ideally, this would be the project plan that is created and the numbered chevrons (Initiate, Plan, Design, Create) would be high level milestones.

Along with these steps there are key items to consider when establishing an Architecture Review Board:

1. Build the Case – This is your business case proposal to present to senior management. This is usually in the form of a PowerPoint deck that delivers the key points at a level that senior management wants to see. It should contain the value of such a board. Understanding what Key Performance Indicators (KPI’s) should be derived will aid in your proposal. You should specifically get ahead of some common questions regarding overhead and bureaucracy.
2. Do Just Enough ARB – Determine your Enterprise Architecture Capability and IT Organizational maturity to derive how your ARB will function. Remember, you should have a multi-program approach to the ARB. You will not achieve the desired state overnight.
3. Gap Analysis – Align ARB with the current governance structure and determine gaps that should be filled. Keep your eye on the high value, low friction items to tackle first in the beginning.
4. Communicate – Build the ARB Communication Plan and keep to it. It is critical, especially in the creation of the ARB framework to keep stakeholders and customers of the progress and decisions for the board. After the creation of the ARB it will be important to send out communications of decisions, value demonstrated and key developments of the board framework.