Mike The Architect

International Standards, Reference Models and Publications Quick Guide

Van Haren Publishing recently published their 2012 - 2013 Global Standards and Publications book free online for all to use. 

I look at this book as a quick guide or a primer to the landscape of standards globally. The purpose isn't to give you deep knowledge into each one of these but rather give the overall landscape of standards that you can leverage in your day to day architecture efforts. As you seen in frameworks like TOGAF where the first step in is to "Select Reference Models", this is a one list you can pull from to see if there is any reuse out there so you don't have to go into the "think tank" and reinvent a practice, standard or tool that is already been vetted in the community. 

This book does a great job pulling in emerging standards and even some of the lesser known ones as well from around the globe. Below is a list of the standards covered in the book:

• Agile
• Amsterdam Information Management Model (AIM)
• ArchiMate®
• ASL®
• Balanced Scorecard
• BiSL®
• CATS CM®
• CMMI®
• COBIT®
• EFQM
• eSCM-CL
• eSCM-SP
• Frameworx
• ICB®
• ISO 9001
• ISO 14000
• ISO/IEC 15504
• ISO/IEC 27000 series
• ISO 31000
• ISO 38500
• ISO/IEC 20000
• ITIL®
• Lean management
• M_o_R®
• MoP™
• MSP®
• OPBOK
• P3O®
• PMBOK® Guide
• PRINCE2®
• SABSA®
• Scrum
• Six Sigma
• SqEME®
• TMap® NEXT
• TOGAF®

 

Download the publication here:

http://www.vanharen.net/file/PDF/Global_Standard_And_Publications.pdf

 

 

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

 

The Open Group SOA Governance Framework Becomes an International Standard

The Open Group has moved the technology industry forward yet again with its second international standard on SOA.The Open Group SOA Governance Framework is now an International Standard, having passed its six month ratification vote in ISO and IEC.

This will be the second since January 2012 when the Open Services Integration Maturity Model (OSIMM). The Open Group has certainly have been getting a great deal of momentum on it's SOA OSIMM as it is being considered for adoption as a national standard in countries such as China and Korea. While this framework has been around for awhile it is great to see the broad acceptance internationally.

SOA governance is critical to all SOA implementations. Just like with building a road, laying the asphalt is just the beginning. That road will need  governing aspects such as the law and maintenance plans. The same with SOA implementations, deploying an ESB with some web services is relatively easy but making sure that those services are adopted and sustainable, that is tricky.  Having a standard way of addressing SOA governance is not only an accelerant to companies but also allows them to:

• Leverage a universally accepted and trusted framework
• Exposure to an evolving framework that is leveraged by many companies that contribute to the Open Group with best practices,  guidance and standards
• Eventually tap into a network of SOA practitioners that understand the standard without training
• Potential for certifications to validate competencies and skills

The Open Group SOA Governance Framework includes a standard governance reference model and a mechanism for enterprises to customize and implement the compliance, dispensation and communication processes that are appropriate for them. Long term vitality is an essential part of the framework, and it gives guidance on evolving these processes over time in the light of changing business and technical circumstances, ensuring the on-going alignment of business and IT.

What I really like about this model is that SOA Governance is viewed as the application of Corporate Governance, IT Governance and EA Governance to Service Oriented Architecture. This shows that SOA Governance extends IT and EA Governance ensuring that the benefits that SOA extols are met. This requires governing not only the execution aspects of SOA but also the strategic planning activities.

Take a look at the new standard, it is certainly worth the read!

Resources

• The Open Group SOA Governance Framework Source Book on The Open Group Website
• The Open Group SOA Work Group
• The Open Group Cloud Computing Work Group
• IBM’s library, which offers papers and services to help with developing a SOA Governance Regimen: http://www-01.ibm.com/software/solutions/soa/gov
• Gartner – SOA Governance remains crucial – http://searchsoa.techtarget.com/news/1261208/Gartner-SOA-governance-remains-crucial
• Gartner – SOA Governance – http://www.zdnet.com/blog/service-oriented/soa-governance-siloed-thinking-top-of-mind-at-latest-gartner-confab/6254

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

The Open Group Certified Architect (Open CA) Program Distilled

In my last post I announced that I received my Open CA certification with a brief description on it, along with the differentiation between Open CA and TOGAF certification. This post actually sprung a series of questions from folks wanting to know more information on the certification program. I thought I would share my “Distilled” version to you here in one post and you can refer to the detailed stuff on the Open CA site.

Brief Overview

The Open Group Certified Architect (Open CA) certification program – formerly ITAC – was created in 2005 and now has over 3,150 certified people from 160 companies in over 60 countries worldwide. Open CA is the market-leading independent benchmark by which to identify the existence and validity of an IT or Enterprise Architect‟s skills and experience.

The overview video can be found here: Open CA Overview

The Open CA program allows individuals to differentiate themselves from other IT professionals by achieving a certification that is:

• Skills and experience-based - Open CA goes beyond validating the mastery of any specific knowledge base, ensuring that certified IT Architects possess and exhibit characteristics commensurate with professional criteria based on best practices.
• Peer-reviewed - You attend three one-hour Board reviews by certified IT Architects who ensure that your skills and experience meet the qualification standards.
• Vendor-neutral - Open CA certification criteria are developed by a consortium of globally-recognized industry leaders and the programs are administered by The Open Group – a trusted, vendor-neutral organization.
• Global - The program adheres to a worldwide set of standards.
• Portable - Certification applies to the individual and not the organization and is therefore fully transferable.

 

 

The Process

The program is based upon four key documents:

1. The Certification Policy, which sets out the policies and processes by which an individual may achieve certification.
2. The Conformance Requirements, in which the skills and experience that a Certified Architect must possess are documented
3. The Accreditation Policy, which sets out the policies and processes by which an organization may achieve accreditation
4. The Accreditation Requirements, in which the criteria that must be met by an ACP are documented

 

 

Levels of Certification
There are three levels to the Open CA certification. The level depends on where you are at individually on your architecture career path (i.e., the length and characteristics of your experiences).  When I was researching this for my certification I reviewed the Certification Guide, Conformance Requirements (Multi-Level) and the Open CA Self-Assessment. 

Just like all certifications, I would suggest to be humble and honest with yourself when selecting the right level for you. You don’t want to set yourself up for failure if you just not ready yet. It’s OK to be a level 1 or level 2 architect, both are very respectable and difficult to achieve.

Each level is shown below:

 

 

These levels as shown above are described as follows:

• Level 1: Certified – able to perform with assistance/supervision, with a wide range of appropriate
  skills, as a contributing architect
• Level 2: Master – able to perform independently and take responsibility for delivery of systems
  and solutions as a lead architect
• Level 3: Distinguished – effects significant breadth and depth of impact on the business via one
  of three advanced career paths: Chief /Lead Architect, Enterprise Architect, or IT Architect
  Profession Leader

 

Advanced Career Paths

So you maybe wondering, what is the difference between these advanced career paths specified in level 3. I wondered that myself as well. I had to dig a little to find it but I finally did. Below is an updated version of the model with the key theme for each career path.

 

 

As seen above:

• Chief / Lead Architect is focused on the strategic and broad impact that EA promises. This level not only leads major initiatives but also runs an Enterprise Architecture organization in a role of Chief Architect.
• Enterprise Architect is a very deep expert in the art and science behind architecture. This person lead major initiatives and has impact on the business through bespoke technology savvy.
• Profession Leader represents the architecture profession. Think of this person as an enterprise architecture evangelist. In most cases this person is running EA communities within a company, up-leveling competencies of their architecture capability, discovering and applying new architecture practices and most likely doing a great deal of publishing.

 

Below is a cheat sheet I created during my research. It’s an image that you can download and use. If you want to modify or tweak to a format of your own, a text based version is below it.

 

or text version:

Chief/Lead IT Architect	Enterprise IT Architect	Profession Leader
Strategic and Broad Business Impact	Expert in IT Architecture	Represents the IT Architect Profession
The role of the Chief/Lead IT Architect is: · To initiate, business justify, and lead projects for the development of new and sufficiently complex components within the enterprise architecture in the areas of information, applications, and technology, in order to meet business objectives · To establish an architectural framework that is the foundation for other systems across the organization and is essential for the proper execution and delivery of critical and strategic business systems · To implement organizational-wide initiatives aimed at supporting the enablement of the IT Architect community through the development of tooling, education, or career enhancement	The role of the Enterprise Architect is: · To lead the creation and realization of sufficiently complex enterprise architectures · To establish an architectural framework that is the foundation for other systems across the enterprise and is essential for the proper execution and delivery of critical and strategic business systems · To implement enterprise-wide initiatives aimed at supporting the enablement of the Enterprise and IT Architect community through the development of tooling, education, or career enhancement	The role of the IT Architect Profession Leader is: · To promote, establish, or maintain the need, value, and presence of an organization’s IT Architect profession (or architecture consulting practice) · To evangelize the IT Architect profession within the organization and externally to promote the continued development and effective utilization of the IT Architect community · To develop and/or maintain and deploy an organization’s IT Architect profession career development model · To establish and manage an IT Architect profession skills and experienced-based profession model that includes a rigorous validation process (for example, Open CA certification – direct or indirect)
The Chief/Lead IT Architect is: · An expert in the understanding of architectural principles and their implications to system design, securability, system extensibility and interoperability, costs, and operational considerations · A student of the profession that is constantly learning and applying new techniques and technologies and seeks to design new innovative architectural solutions	The Enterprise Architect is: · An expert in the understanding of architectural principles and their application to business architecture, performance management, organizational structure, and process architecture as well as IT architectural aspects such as system design, security, cost, and operational considerations · A student of the profession that is constantly learning and applying new techniques and technologies and seeking to design new innovative architectural solutions · A contributor to the profession; by providing best practices and concepts to refine enterprise architecture methodologies, frameworks, and techniques based on practical experiences	The Enterprise Architect is: · An experienced practitioner who retains the understanding of architectural principles and their implications to system design, securability, system extensibility and interoperability, costs, and operational considerations · A student of the profession that is constantly learning how the organization can utilize and apply new techniques and technologies and seeks to design new innovative architectural solutions · An effective leader who influences organizational structure by leading an organization’s IT Architect profession programs and initiatives

 

I hope you found this helpful. If you are thinking of becoming Open CA certified, best of luck and I hope these materials helped accelerate you on your journey.

 

For more information see these resources:

• Open CA Site
• Conformance Requirements (Multi-Level) – Skills required
• Guide for Getting Started
• Certification Guide
• Sample Certification Packages
• List of recognized architecture methods can be found here
• Sample Certification Agreement
• Reference Letters FAQ

 

Technorati Tags: Open CA,Open Group,ITAC,Enterprise Architecture,Enterprise Architecture Certification,Certification,EA

Open Group Rebrands Certification Programs

This week The Open Group IT Architect Certification (ITAC) program has now become The Open Group Certified Architect (Open CA) program. The IT Specialist Certification (ITSC) program has now become The Open Group Certified IT Specialist (Open CITS) program.

With the name change, there hasn’t been many changes made to the way in which either program operates. For example, the Open CA program still requires candidates to submit a comprehensive certification package detailing their skills and experience gained on working on architecture-related projects, followed by a rigorous peer review process.

The Open CA program still currently focuses on IT-related work. However, the architecture profession is constantly evolving and to reflect this, The Open Group will incorporate dedicated Business Architecture and Enterprise Architecture streams into the Open CA program at some point in the near future. Our members are working on defining the core skills that an architect needs to have and the specific competencies one needs for each of these three specialist areas. Therefore, going forward, applicants will be able to become an Open CA in:

• IT Architecture
• Business Architecture
• Enterprise Architecture

There are approximately 3,200 individuals who are certified in our Open CA program, and by broadening the scope of the program we hope to certify many more architects. There are more than 2,300 certified IT Specialists in the Open CITS program, and many organizations around the world have identified this type of skills- and experienced-based program as a necessary part of the process to develop their own internal IT profession frameworks.

Open CA and Open CITs can be used in the recruitment process and help to guarantee a consistent and quality assured service on project proposals, procurements and on service level agreements. They can also help in the assessment of individuals in specific IT domains and provide a roadmap for their future career development.  You can find out more about our programs by visiting the professional certification area of our website.

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

Navigating through the Complexities of Architectures

A common challenge among architects and architecture organizations is the challenge of properly understanding the landscape of architecture assets within and external to the enterprise. With all the different definitions, hierarchy and levels of abstraction it can be difficult to really get your arms this problem space.

At an architecture summit were questions like:

• What is a pattern?
• Is there a difference between a reference architecture and a pattern?
• How would you classify an architecture asset?
• What is the difference or the line between architecture and implementation?

These are all great questions and I am sure there are questions asked by many others as well.

There are things you can do to alleviate this pain. Below are four activities I have used to help clear up the confusion:

• Lock on Vocabulary - A large part of the problem (not the only) is one of vocabulary. Having a common definition for these terms goes a long way. After walking through the questions above with architects what we quickly found was that we were actually deriving to the same definition but using different terms.
• Classification – As you go through the terms there will be quite a bit of iteration on the relationships of these terms. This classification or taxonomy is important to lock for your organization. It helps you understand the context and the relationships of the asset to all other things. 
• Leverage Mainstream Vocabulary and Classification – In a past experience of mine (7 or so years back) when aiding in building an Office of Enterprise Architecture we found this same issue of locking on terms we can all understand as an enterprise. We spent the better part of 6 months (in duration not effort) just trying to lock on terms. This involved passionate debates and religious wars on how people understood the space and their personal preferences. Save yourself the heartache and leverage an existing standard. It will be better for your organization in the long run.
• Provide Examples – Run through a few scenarios to exercises the vocabulary and classification system. This will accelerate the end users understanding of the concepts.

 

There has actually been quite a bit of work done in this space. The Open Group’s TOGAF 9 has defined this space really well at the macro level. This is what they call the Enterprise Continuum. There site has a lot of detail on this and you can find more on the Enterprise Continuum Online Book Chapter. 

The definition of the Enterprise Continuum is: a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures

So essentially it is providing a classification and common set of definitions for the space. There is a small bit of taxonomy work here but it is inferred not in a typical taxonomy format but the outcomes are that of a taxonomy.

 

I really like that this framework accommodates real world challenges such as regulatory compliance, business change, technology disruptors and competitive forces. This is all rationalized in the context of business and IT strategy which is a first class citizen in the framework.

This is demonstrated in the diagram below when you look at the traceability aspects of the framework.

Above shows abstraction at a high-level and below is an exercised high-level architecture partitioning of the model that can be mapped to the ADM methodology. This is what makes the model actionable as it leverages the deep definition of an architecture method to make the classification implementable.

 

If you are looking to supplement TOGAF or look at other perspectives there are great resources at the OMG, IEEE, FODA, and others. Of all the sources TOGAF (in my opinion) is by far the most complete across the spectrum and is the highest used by both enterprises and tools vendors.

Another helpful piece of context setting which isn’t necessarily in the Enterprise Continuum is the notion of an Architectural Style. I talk about his in a post I wrote a couple years back in “What is an Architectural Style” . I think that this is complementary to the Enterprise Continuum as it is more of guiding principles of the Architecture and Solution Continuum.

I define an architecture style as:

An Architecture Style is a logical grouping of patterns or architecture references that is implemented through cohesive methods for solving a problem area with a unique set of concerns.

 

At the time this was a way to reduce confusion around key macro technology patterns such as SOA, now this has shifted to another amorphous concept of Cloud Computing. See below for an example:

 

Additionally, J.D. Meier has a good post on Reference Models, Reference Architectures and Reference Implementations that could be either worked into the TOGAF vocabulary but also used independently if need be.  The reason I bring this post up is that he has some good definitions that could be an alternative or provide additional context.

See J.D.’s descriptions below:

• Reference Model - A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes. It’s like holding up a diamond and looking at the different facets. It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives. They are also useful for pulling together a bird’s-eye view of a domain or problem space. A well-known example is the OSI model. Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context. By using a model, you can focus on higher-level concepts, ideas, and decisions.
• Reference Architecture - A reference architecture provides a proven template solution for an architecture for a particular domain. It’s the high-level “blue prints” for putting the pieces of the puzzle together.
• Reference Implementation - A reference Implementation goes beyond a reference architecture and is an actual implementation. This is where the rubber meets the road and it serves as an exemplar down at the implementation level.

 

Technorati Tags: Enterprise Architecture,EA,Open Group,TOGAF,Taxonomy

Book Review: Troux Enterprise Architecture Solutions

I recently picked up a copy of Troux Enterprise Architecture Solutions by Richard Reese. I have worked with Troux in a variety of capacities in the past along with stacking them up with the other large Enterprise Architecture Tool vendors. I was naturally interested to see what guidance they have outside of the guidance used to operate and support the actual tool.

I was really surprised by the book as it went in a different direction than I thought it would. I expected the book to be largely about the tool. Using the tool as a lead in to the other Enterprise Architecture topics. This wasn't the case at all but rather the complete opposite. Those aspects were pleasant to see.

I have mixed reactions about the book. Just like with everything there are he good and bad aspects. Below are those aspects that I was able to distill out of the book.

The Good

• Practical Models - I really like when authors use real world examples. Obviously there are limitations to this from an IP perspective, however to show how these abstract concepts in  relatable scenarios that the reader would run across is extremely important.
• Right level of Theory and Practice - The book isn't too abstract as EA can get sometimes. There is a theme of practicality to the book.
• Visualizations - the chapter on visualizations was really drove the point home. It gave the reader a view into the tangible capabilities of Troux. There should be more of this in the book. My only negative here is that I wish the author would of gone into more details on the methods and processes that support these visuals. My fear would be that people would use these out of context. It would of been good to have more chapters like this one with rich visuals.
• TOGAF Alignment - Overall this chapter was good as well it provided a good overview and touched how Troux addressed TOGAF. I would however would of liked to see on a feature to process alignment matrix to show how much coverage Troux had on the tool.

The Bad

• Message and Purpose Diluted - I know this may seem fairly harsh, but I found the book to jump around quite a bit. There was a real flow issue with the book content. An example of this is Chapter 5 where organizational models are gone into depth while other chapters such as Metadata, business values or business alignment are either briefly covered or partially covered. After I read the book I wasn't able to takeaway a key message or theme that the author was trying to drive. This led to more questions than answers. That may of been the intent but it would of been setup for the expectation early in the book as I didn't walk away with "Troux Enterprise Architecture Solutions".
• High Level - This contradicts a positive point, I know, but the book was detailed in some areas and extremely vague in others. I think this is what really hurts the book.
• Transformation Platform Architecture - I was really surprised by this chapter. I was expecting more on how to make a platform like Troux scalable functionally along with key patterns to enabling Troux as the EA Knowledge Management tool. However, this chapter doesn't use the same principles that are described to model architectures and doesn't illustrate the architecture of the Troux solution very well. It would be good to see the same models and methods used for LOB applications used to decompose Troux platform to drive the message home.
• Metadata Management - This chapter went from theory directly into technical configuration really fast. While I really liked the trade-offs between centralized vs. decentralized repositories, I was expecting more tangible examples for the readers on the value and uses of metadata management, architecture Ontologies and Taxonomy and the impacts of social computing on how metadata can be enriched. This could of led to a great set of visuals, use cases, examples of kinds of metadata, formats, key lessons learned and how Troux could make metadata much more manageable and ultimately much more usable.
• Business Alignment - This chapter was all over the place. There was only one example of alignment and it was from a relatively unknown company. If there was a few companies that could be used as the basis for the methods it would of made this chapter so much better. However without real statistics, business process improvement or value realization metrics this chapter didn't convince me as a reader.
• Governance - This chapter only focused on standards and the tool. There was no mention of process or people. This is only a very, very small aspect of governance. The organizational structures while fictitious, is a bit misleading as most organizations have a variety of different structures. Finally there was no mention of organizational readiness or maturity that will ultimately drive the activities in which architects establish.
• Generating Business Value - This chapter was all over the place and was extremely high level. Not a whole lot of value gotten. I found most of the techniques mentioned were out of date with the industry. I was surprised by the RAD comments as this term is really outdated. Agile methods have surpassed RAD and have tangibly demonstrated its value. Why Agile methods are not mentioned was concerning as this is the world today not waterfall or RAD. I expected that to be addressed along with how it fits into EA or Troux.

In summary, the book was a bit of a let down for experienced Enterprise Architects but could be useful as a primer of EA's getting into the role that their company uses Troux. Even in that case this book should be supplemented with another set of resources to balance out the details.

Regardless, check out the book for yourself as there is a wealth of visuals that can stimulate you to think about how to make better IT decisions and to better position the value of EA.