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:
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
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
- 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
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.
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.
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.
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:
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:
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