Mike The Architect

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

 

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

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

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

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

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

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

 

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

Open Group Complements TOGAF with SABSA Integration

The Open Group announced last month the release of the TOGAF & SABSA Integration Whitepaper, a new guide developed in collaboration with The SABSA Institute to enable enterprise and security architects to integrate security and risk management approaches into enterprise-level architectures. Endorsed and developed by The Open Group Security and Architecture Forums and The SABSA Institute, the whitepaper aims to help architects align IT security decisions with critical business goals while reducing costs and improving interoperability across the enterprise.

 

"For too long, security and risk management have been considered a discipline separate from enterprise architecture, which has led to increased costs, reduced interoperability and less productive organizations. This guide empowers enterprise architects to apply a holistic, business-driven approach to IT security decisions," said Jim Hietala, VP of Security for The Open Group. "Like TOGAF, the SABSA methodology provides guidance for aligning architecture with business value, in addition to addressing a critical need for greater integration between security and enterprise architectures within organizations."

Intended as a practical guide, the whitepaper views security architecture as an integral part of how enterprise architecture should be approached, a critical shift that is often overlooked in enterprise architecture frameworks but that encourages enterprise architects to focus attention on business processes rather than just technology solutions. To address security and risk management more effectively within enterprise architecture frameworks, the whitepaper also describes ways that TOGAF and SABSA can be seamlessly integrated for optimum security and business productivity. This includes detailed guidance on how to produce business and risk management-based security architectures, along with practical approaches to improve the integration of information security across the enterprise. Within this context, a main objective of the paper is to spark debate in the enterprise architecture community about the evolving role of enterprise architects in enabling the business to manage operational risk.

"In the past, security and enterprise architectures have been designed and acquired in silos, without common architecture languages that help tie both to broader business objectives," said John Sherwood, Head of the SABSA Academy, a division of The SABSA Institute. "We're proud to integrate SABSA with TOGAF finally to provide structure for the relationship between enterprise and security architectures, and help create more efficient, cost effective and productive enterprises. Our hope is that the paper will fundamentally change the way enterprise architects think about enterprise architecture."

The SABSA methodology was chosen for integration with TOGAF based on its objective of developing security architectures that facilitate the business, much like TOGAF's business driven approach and open methodology. Utilizing the SABSA Business Attributes Profiling method, the integrated methodology enables the creation of better architectures that drive tighter alignment between business and IT within enterprises. The whitepaper is the culmination of the TOGAF-SABSA Integration Project that began in May 2010 as a joint initiative of The Open Group Architecture Forum, Security Forum and The SABSA Institute.

The TOGAF SABSA Integration Whitepaper is available here: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

 

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

Enterprise Architecture Certifications Distilled

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

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

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

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

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

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

 

Enterprise Architecture Certification Reference Guide

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

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

Below is a description of each aspect:

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

 

 

Resources

Competency Based Certifications

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

 

Industry / Specialized Certifications

• FEAF
• TEAF
• DODAF

 

Foundational Certifications

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

 

Supporting – Academic

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

Supporting – Applied and Tailored

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

 

 

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

What you need to know about TOGAF 9.1

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

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

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

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

 

What’s New, Modified and Removed

Material that has been removed:

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

Material that has been substantially revised:

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

Areas where inconsistent use of terminology has been addressed:

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

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

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

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

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

Certification

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

 

Resources

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