Mike Walker's Blog

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.

Microsoft’s Certified Architect (MCA) replaced by IASA’s CITA-P Certification

IASA’s CITA-P Certification Named by Microsoft to Replace the Microsoft Certified Architect
Austin, TX, (PRWEB) May 3, 2010 -- In a conference call and email announcement on Wednesday April, 28, Microsoft Learning announced that it would discontinue offering the Infrastructure and Solutions architect certifications, and would fund the migration to the Certified IT Architect Professional (CITA-P) offered by the International Association of Software Architects (IASA).

IASA has created a grandfathering process to allow easy adoption of the CITA-P certification for current Microsoft Certified Architects holding the Solutions or Infrastructure specialization. As MCA’s have already gone through a rigorous interview process similar to the CITA-P Board review, the grandfathering process focuses on mapping skills and experience to the IASA skills taxonomy.

Andy Ruth, the Vice President of Education for IASA, launched the MCA Infrastructure and the MCA Solutions credential in 2004 while with Microsoft Learning. According to Microsoft, the credentials were launched to help establish the IT Architect profession at a time when the IT industry needed thought leadership and architectural taxonomy.

Ruth believes the profession should be self managed by the practitioners in the form of a professional association, as in other industries--medical, legal, etc. “The certification of a profession needs to be run by the profession, not from within a vendor with a specific product or technology. Microsoft releasing the certification to IASA is recognition of that.”

“IASA is not trying to sell a product or specific technology, so individuals and organizations can be confident there are no ulterior motives in their certification and education programs,” said Paul Preiss begin_of_the_skype_highlighting end_of_the_skype_highlighting, CEO of IASA. “IASA’s mission is to support architects on their career path, and ensure they have the skills and knowledge necessary to deliver on the core value proposition of the profession: to make and save their employer money through the use of information technology (IT).”

Darren Day, Microsoft Certification Business Manager, who hosted the call for Microsoft said that IASA has "developed large and supportive communities dedicated to the IT Architect profession.” He continued, “They are technology agnostic, respected in the industry, and offer trusted IT architectural programs and credentials for the breadth architect.”

Read the entire release at: http://www.prweb.com/releases/2010/05/prweb3946754.htm or go towww.iasahome.org to find out more.

ArchiMate - The Emerging Architecture Modeling Standard?

At the Gartner EA Summit in London it seemed like there was quite a bit of talk on the solution showcase floor regarding an architecture modeling standard called Archimate. I'm not sure if this was due to the fact that this was a European event (ArchiMate derived from the Netherlands) or if there is truly significant reasons to have the buzz.

It looks like there are two primary drivers behind all the buzz:

• Open Group has now adopted
• Customer & Tooling Vendor up take

 

What is ArchiMate?

If you are not familiar with ArchiMate, it is open architecture modeling standard. It focuses on the visualization of viewpoints and notations on models. It was a result of a 4 million Euro Dutch Government project to create a unifying architecture modeling standard. The standard conforms to the traditional BAIT model (Business, Application, Information, Technology) for representing architecture descriptions.

There are some unique details to the ArchiMate standard which include how they implement behaviors. You can see this in the meta-model below:

There is a notion of the Structure and the Behavior aspects of an architecture. There is a clear separation in the ArchiMate implementation.

Another thing I like about ArchiMate is that it focuses on a core problem rather than trying to solve many problems in a not so great way. This of course is architecture modeling. The models are at a higher level of abstraction than design or development models. Do you see limited or no overlap with standards such as UML and BPMN. There are touch points in these other modeling languages. AchiMate can also be stitched into existing EA frameworks such as TOGAF. There are resources available that describe the touch points between the modeling standard and the EA process framework.

If you are not familiar with ArchiMate I would recommend the following sources to get caught up:

• ArchiMate Quick Reference & Using ArchiMate
• Open Group ArchiMate site
• Sethuraj Nair post "Archimate It's Time had Come"
• Open Group Research Work

 

Vendor Support of ArchiMate

Arguably one of the major deciding factors in a standard is the uptake and productization of the implementation of a standard. Surprisingly, there has been a great deal of recent activity with picking up this modeling standard.

There were a lot of vendors that claimed that they had support for it. These include:

• IDS Sheer
• Bizzdesign Architect 
• Casewise 
• Avolution Abacus (not at the conference)

 

For all the folks using Office tooling there is a solution for you as well. ArchiMate stencils for Microsoft Visio.

 

Open Group and ArchiMate

From what I can tell with talking with some Open Group members here at the conference is that the Open Group has indeed picked up ArchiMate. There is still discussion in the architecture working groups around how this will be positioned, aligned and evangelized by the Open Group.

As you can see from the agenda items for the upcoming Munich event, there is a great deal of planning that still needs to occur.

• ArchiMate Standard Version 1.0
• ArchiMate certification

• 2009 Planning and Discussion
• Formation of workgroups and standing committees
• Coordination status with other groups
• Charter discussion and approval

 

So back to the question, is ArchiMate the next big modeling standard for architecture? It has the potential to be so. As mentioned before, between the Open Group and the tool vendors the standard is coming out strong. It is hard to tell at this point. We really need to see this in the wild to really get a grip on if this is yet another academic standard or something that is adoptable by the masses. 

I think ArchiMate had found a good home at the Open Group. TOGAF does a great job at the process but needs more grounding standards to make TOGAF all that more actionable for enterprises.

Technorati Tags: Modeling,Enterprise Architecture,TOGAF,ArchiMate

Making Sense of Architecture Standards

416

Yesterday I attended the Architecture track at the Microsoft MVP (Most Valuable Professional) Summit. The format was quite different than other forums. The architect forums was based on a collaborative approach where three is no agenda or themes and it is up to the participants to create it. It was very effective and thought I would share my thoughts with the rest of you.

So I facilitated two sessions on Enterprise Architecture. The first asking the question, what is EA? And the second, what are the important standards in the EA space?

The goal of the second session wasn't necessarily trying to get at what are the standards but rather what are the more prevalent and most impactful.

After a bit of white-boarding with the group and dialog we quickly derived to a way to classify the standards that we have been talking about.

The image above show the segments or classification of these standards. By asking basic questions such as How, What, When, Who and Why we can also simplify this a bit. Starting from the bottom up lets talk about what was discussed and I'll add some of my thoughts as well.

Taxonomy and Ontology

Every system has an architecture. In fact, a system could have many architectures. In IEEE 1471, an architecture is a conception of a system. There may be many conceptions of a system.

What this provides to the enterprise architect, solutions architect or domain architect is a way to have a constant set of terms for describing what it is they are building. This should be at the core to your architecture activities. Downstream benefits include further reuse of architectures, design patterns, architecture modeling and traciablity of systems to business capabilities.

The beauty of all this is that this taxonomy is flexible. Meaning that System, Mission, Environment and Architecture, are all conceptual in nature. There are no requirements ("shalls") in the standard pertaining to these entities. The requirements in the standard apply to the items below which pertain to the concrete representation of an architecture.

For more information on IEEE 1471 go to their web site at: http://www.iso-architecture.org/ieee-1471/index.html

 

Information Model and Decision Support

The Zachman Framework was brought up many times during the conversation but in various forms. We ended up classifying Zachman as decision support. The reason for this was that Zachman and other derivatives of Zachman focus more on:

• What are the right questions
• How do I organize those questions
• What do those answers mean

The Zachman Framework excels at these activities. However where things start to break down is how to orchestrate those questions. Meaning what is the process in which I get the information, consume it, process it and ultimately make it actionable.

The ideal goal here would be to use the Zachman Framework in conjunction with the Process Capabilities coupled with a defined Architecture Taxonomy.

For more information visit the Zachman Framework  web site at: http://www.zachmaninternational.com/2/Zachman_Framework.asp

 

Process Framework

As mentioned above when talking about decision support, there is a need for a process to wrap how we make our decisions. This gives Enterprise Architects the ability to have repeatability in their processes.

Below you will see the TOGAF Architecture Development Method (ADM) "crop circle" which outlines the process framework.

ADM provides a framework which can support man other standards and frameworks. It is technology agnostic and is more focused on how architecture processes should be orchestrated. This allows organizations to:

• Preserve existing organizational structures (if desired)
• Use homegrown processes and existing frameworks and standards

Having this higher level process framework is essential to architects. Thee are a series of benefits for the organization:

• Constancy in how solutions are created
• The right people are selected for the right job
• Proper metrics can be obtained to gauge health of the EA process
• Predictability of results which lends to being able to apply some level of risk management to decisions

Actors

Out of all the topics, this was discussed the most. There is a great deal of ambiguity in the industry around what are the required skill sets of an architect. There are some bodies that help with that task.

• OpenGroup ITAC Program - This is for the practitioner. When you have many years of experience and you want to be accepted in the industry as a credible architect.
• IASA - For the aspiring architects that is largely academically focused. This program provides a program for those that have little architecture experience and want to get into architecture.

Both have a role and are valid in their own ways. However, each one of these has a specific niche.

Manage

This topic is indirectly related but still very relevant. This aspect covers PMO based processes, service management and IT Governance aspects. In the service management area specifically we are seeing closer alignment with EA. The latest version of ITIL has alignment with EA practices.

See my previous blog post: http://blogs.msdn.com/mikewalker/archive/2007/07/06/itil-moving-towards-enterprise-architecture.aspx

 

 

Putting it all Together

Thankfully there have been other like minded individuals folks at OpenGroup and alike that have thought about this problem. Below are some overlays and descriptions of putting these pieces together.

TOGAF + Zachman

Read this article for more information:

http://www.opengroup.org/architecture/togaf8-doc/arch/chap39.html

 

TOGAF + IEEE 1471

TOGAF adoption of IEEE 1471 happened in 2000 with TOGAF version 6.0. There is a great article that gives an impact assessment on this and the benefits of using 1471 with TOGAF.

http://www.enterprise-architecture.info/Images/Documents/IEEE-1471-togaf-impact.pdf

 

Other Important Standards & Frameworks

It's important to not that there are a lot of standards out there. We haven't scratched the surface on all the various specifications and standards for EA. Below you will find other standards that you may be interested in as well.

Other EA Frameworks

• DODAF
• TEAF
• FEAF
• CADM
• MODAF

 

Tags: Enterprise Architecture