Mike The Architect

US Navy Updates it's Enterprise Architecture Framework to 4.0

The United States Navy released it's department of Defense and the Navy (DON) Enterprise Architecture Framework on 4.0.

Like with all other US government agencies they are federally mandated to have enterprise architecture (EA) established to support their IT strategies and to capitalize on their vast technological assets and make sound decisions about investments in new technology. 

Below is a snapshot of the EA method for Supporting IT Business Transformation portion of the framework:

Background

The DON Chief Information Officer (CIO) is leading the effort to design and develop a single DON EA, using a strategy that federates with external partners and incorporates an integrated, coordinated, flexible and long-term strategically focused approach. The DON EA describes the processes, information flows, solutions, data descriptions, technical infrastructure and standards that are integrated to achieve current and future DON strategic goals and objectives.

The DON EA assists decision makers in the execution of major decision processes such as the Defense Acquisition System, Planning, Programming, Budgeting and Execution, and the Joint Capabilities Integration and Development System.

Interestingly enough, since the release of the Global Information Grid (GIG) Federation Strategy in August 2007, the DON CIO has tailored the federated approach in developing and managing the DON EA. The DON EA will federate with DoD and other external partners.

For more information: http://www.doncio.navy.mil/ContentView.aspx?ID=4175 

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

 

EA Classification, Understanding, and Frameworks

I ran across an interesting article today written by Mike Rosen on Enterprise Architecture Frameworks. He shares a similar belief as I on these. Ironically I was going to post something along these lines as well. I just sat in a one day course on Zachman and EACOE and was going to distill my thoughts. I will see what is different from this article and expand on my key observations from that training.

Below is the article abstract and link. This is in a controlled subscription area.

 

Abstract

In other words, data is a collection of unorganized/uninterrupted facts. When we put those facts in the context of a schema or classification, then we have useful information. When we put that information into the context of experience, then we have knowledge. When we apply that knowledge to add value, then we have wisdom.

Full Article
http://www.cutter.com/content/architecture/fulltext/advisor/2011/ea110615.html

New set of MOF 4.0 Materials Released

Over the past few weeks Microsoft has released a series of new guidance in their Microsoft Operations Framework (MOF). Those releases have both been in the form of betas and full releases. 

For those that do not know what MOF is, it is essentially ITIL lite. It is made up of a series of light weight checklists and templates to help make more sophisticated service management frameworks such as ITIL much more actionable. 

MOF Release Information

The MOF/Microsoft products companion guides bridge the gap between high-level service management processes and real-world application by clearly outlining how to apply MOF concepts using Microsoft products. The best practices outlined in this guidance will help facilitate collaboration between IT process and IT technology professionals, and make it easier to achieve improved service management outcomes in a timely manner.

Diagrams of MOF Management Reviews, which summarize the concepts outlined in the corresponding guide, are intended to help organizations ensure that their IT services are on track to deliver expected value. The colorful graphics logically put the goals, process flow steps, key terms, outcomes/metrics, and role types of each management review into context. The visual representations provide the knowledge to help management set goals, evaluate progress, and confirm results.

The reliability workbooks present hands-on tasks that you can fine tune to meet the goals of your organization and the technologies that you use.

• Bridging from MOF Guidance to Microsoft Products: A MOF Companion Guide: http://go.microsoft.com/fwlink/?LinkId=197223
• Diagrams of MOF Management Reviews: http://go.microsoft.com/fwlink/?LinkId=197224
• MOF Reliability Workbook for DirectAccess: http://go.microsoft.com/fwlink/?LinkId=197225
• MOF Reliability Workbook for Exchange 2010 Client Access and Transport: http://go.microsoft.com/fwlink/?LinkId=197226
• MOF Reliability Workbook for Exchange 2010 Mailbox Services: http://go.microsoft.com/fwlink/?LinkId=197227
• MOF Reliability Workbook for Forefront® Unified Access Gateway: http://go.microsoft.com/fwlink/?LinkId=197228
• MOF Reliability Workbook for SQL Server® 2008: http://go.microsoft.com/fwlink/?LinkId=197230

Open Group SOA Governance Framework

The Open Group SOA Governance Framework provides context and definitions to enable organizations to understand and deploy SOA Governance. It describes SOA Governance; defines an SOA Governance Reference Model (the SGRM) and its constituent parts; and defines the SOA Governance Vitality Method (SGVM), which assists an organization in customizing the SGRM to realize its customized SOA Governance regimen.

 

This generic reference model for SOA governance is provided as a standard, to be used by companies to create (and constantly monitor and update) their own specific governance model and best practices. The SOA governance framework may be used in the context of another governance framework, such as COBIT or ITIL; the SOA working group did a mapping of COBIT to this framework as part of the framework development process, and plan to do more in the future in order to help organizations preserve their investment in COBIT/ITIL training and implementation.

The SOA Governance Framework will be available here for free download:

http://www.opengroup.org/bookstore/catalog/c093.htm

 

Technorati Tags: SOA,Goverance,Frameworks,Enterprise Architecture,Open Group

ArchiMate 1.0 from Open Group, first global language for modeling

It’s official, ArchiMate version 1.0 under the control of the Open Group will be released at the London event in a week. It looks like that is when all the materials will be released publicly online.

Press Release: http://www.opengroup.org/press/21apr09.htm

ArchiMate NEW Home Page: http://www.opengroup.org/archimate/

 

If you are a follower of my blog you will see that I have been watching ArchiMate for some time now. I am very excited that this has been embraced in a larger standards body and am looking forward to it’s growth and maturity.

Right now ArchiMate snaps nicely with the B. Business Architecture, C. Information Systems Architecture, and D. Technology Architecture. But there is more coverage needed across the ADM and detailed aspects of phase B, C, and D.

 

I sat in a great overview session of ArchiMate yesterday from Remco Blom at BiZZdesign where they talked through a lot of this and showed how extensible the standard is. I do hope that they share the webcast to everyone.

One area they focused on was “ArchiMate +” which is what you can do to extend Archimate. See the example below:

 

There was also a thread on Nick Malik’s blog regarding a potential conflict between UML and ArchiMate. I commented on this thread but as of right now it isn’t showing. It may not of been approved yet. But the reader digest version of it is that I think the there is no conflict as ArchiMate is all about the macro-level modeling whereas UML and other standards like it are about the micro-level modeling details. They are complementary in that sense. Could there be overlap, sure. But I think it is up to the architect to draw the line where he/she wants to stop as far as modeling abstraction is concerned. The only area I do see potential conflict is with MDA/MOF, but frankly I haven’t seen a whole lot of uptake of that lately. Personally, I am not a big fan of MDA but rather more of the loosely coupled MDD approaches that allow for multi-views and viewpoints.

 

Previous ArchiMate Posts:

• ArchiMate - The Emerging Architecture Modeling Standard?
• http://www.mikethearchitect.com/2009/03/mapping-current-state-architectures-across-the-enterprise.html
• TOGAF 9 Release and Impressions

 

Technorati Tags: Enterprise Architecture,ArchiMate,Modeling

What EA Framework Do You Use?

Serge Thorn posted a poll on LinkedIn for companies to chime in on what EA frameworks they use. For those of you that use one of the major frameworks you should definitely enter it into the poll. The results benefit us all. So far there are 136 responses (as of today) with TOGAF in the lead with 61% and Zachman at 18%. So far it's a pretty big gap.

You can find the poll here: http://polls.linkedin.com/p/13540/ikhnz

Technorati Tags: Enterprise Architecture, Frameworks

Extended Enterprise Architecture Framework (E2AF) Template

Mike Kavis posted a high level cheat sheet for the Extended Enterprise Architecture Framework (E2AF) on his blog today. Here is the description from his post:

I Basically took all of the topics from the E2AF matrix and built a document with bullets representing each topic. It is organized by the six key questions (Why, With Who, What, How, With What, and When) and has sub categories for each question by the four different view points (Business, Information, Information Systems, Technology Infrastructure). In Appendix A, I included several links to the website where the E2AF information can be found.  Appendix B lists all of the E2AF deliverables.

I am really happy to see Mike Kavis is making this framework more actionable. As you could probably tell from my comments from TOGAF, I see that one of the biggest issues with these frameworks is the execution angle. In general, the template that was posted could be applied to other frameworks or even homegrown efforts as well.

My only critique would be that while the template provided by Mike definitely has all the placeholders and high level areas that are needed to be addressed it will still take some time for folks to digest all the data that needs to go in those placeholders. I would suggest putting more detail around the information that needs to be gathered in each section to help new people to E2AF or any other EA discipline understand what kind of data goes into each section. Either way it’s still a great free template to use as one of the tools in your EA Toolbox.

You can download the document here as a zipped file from his post.

 

Technorati Tags: Enterprise Architecture,E2AF

Share this post :

Can you Easily Compare EA Frameworks?

Have you ever tried to compare EA frameworks? How do you compare and are all frameworks the same. The reader digest version of the answer is: No... Not all frameworks are the same but rather have there own definitions of what they are to deliver.

I have in the past and I have found it very challenging because it is a bit like comparing apples and oranges. When I talk to customers and folks internally about EA frameworks there is a great deal of confusion with current comparisons found online. Below is a common example:

source: http://www.mkern.com/whatisea/frameworks.html

This comparison  really doesn't tell us much detail. Although there is a whitepaper called A Comparison of the Top Four Enterprise-Architecture Methodologies on the MSDN EA Architecture Center we have the same issue with comparing these framework with the same base criteria:

This isn't to say these don't provide value, they do from a macro level. However, the real challenge here is that these frameworks are fundamentally trying to solve different problems all together.

I see that there are two major types of frameworks:

• General Purpose Frameworks - What sets these types of frameworks apart from others is that they are trying to solve the broader problem the enterprises are having. These frameworks do so by being agnostic to any specific implementation. They have no specific business drivers (enterprise specific) but rather are capability based. These frameworks are generally driven by industry consortia such as Open Group.
• Domain Specific Frameworks - Frameworks that are derived from an EA effort are refereed to as Domain Specific. These frameworks were derived with a predefined set of business concerns in mind because they originated from an EA office or process improvement effort in a government or an enterprise. Largely these frameworks are driven by government agencies such as the US government or other geographies.

So how does the actual frameworks fit into these buckets.

General Purpose Framework	Domain Specific Framework
TOGAF	FEAF
Agile EA	DODAF
Zachman	MODAF
	TEAF
	...

Should you eliminate one of these types form your efforts? Absolutely not. These frameworks have very specific value propositions. But we first need to know how they are fundamentally different.

As shown above there are two basic characteristics. We look at the allowable level of customization vs. prescriptive guidance. These frameworks slide down the continuum from the level and ability to customize to the level of prescriptive guidance. The general purpose framework has a greater level of flexibility as it is attempting to solve all problems. Whereas the Domain Specific Framework is solving the problem with a series of predefined set of forces and attributes.

For example: A government based framework such as FEAF / TEAF / FEAF will be based on the specific government based regulatory laws (region based), a set of operating and organizational models that is specific to that agency. These will drive out the process and artifacts required to fulfil these base business drivers.

So what do you get with these different types of frameworks? With these two classifications of frameworks there are a set of artifacts, methods and tools that are derived. These are derived on the the base problem sets defined earlier. Since these are derived, the outputs can be very different. See below:

General Purpose Frameworks:

• Defines an open and consistent definition of terminology through taxonomies and ontology.
• Agnostic to organizational structure
• Low level process agnostic
  • SDLC
  • PMO
  • Service Management
  • etc.
• Very configurable to enterprises

Domain Specific Frameworks:

• Prescriptive guidance for:
  • Organizational structures
  • Processes
  • Artifacts
• Usually deliver lots of templates
• Lots of real world examples

Is the comparison of EA Frameworks like comparing Apples and Oranges? Yes it is. When you compare these frameworks they should not be treated the same nor should be judged based on the same criteria. Rather they should be correlated with your specific requirements. 

Technorati Tags: Enterprise Architecture,Frameworks

Governance For Your OBA's

In last weeks session I was asked about governance and OBAs (at least from a server side perspective). I am happy to report that the community is concerned with governance as well. Microsoft IT Team Site Life Cycle Management Beta 1 was created on Codeplex and is intended to provide governance and manageability samples and tools designed to help IT Professionals management SharePoint Products and Technologies deployments. 

Upcoming tools include an implementation of site/web lifecycle management based on the Site Delete and Confirmation feature, the Microsoft IT Site Delete Capture 1.0 feature, and additional out-of-the-box functionality.  A sample auditing configuration solution deployment package will be introduced in the September-October timeframe that provides guidance on auditing and the management of content types across site collections.

Check out some of more governance content:

SharePoint Technology Governance Information on TechNet

SharePoint Governance posts on Joel's Blog

Manageability and Governance Post

Key Governance Considerations

Information Policies and Auditing Post

Information Architecture Post

Logical Architecture Samples

 

Tags: OBA