Category Archives: TOGAF

The Center of Excellence: Relating Everything Back to Business Objectives

By Serge Thorn, Architecting the Enterprise

This is the third and final installment of a series discussing how to implement SOA through TOGAF®. In my first blog post I explained the concept of the Center of Excellence, and creating a vision for your organization, my second blog post suggested how the Center of Excellence would define a Reference Architecture for the organization.

 SOA principles should clearly relate back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:

  • Put the computing near the data
  • Services are technology neutral
  • Services are consumable
  • Services are autonomous
  • Services share a formal contract
  • Services are loosely coupled
  • Services abstract underlying logic
  • Services are reusable
  • Services are composable
  • Services are stateless
  • Services are discoverable
  • Location Transparency

Here is a detailed principle example:

  • Service invocation
    • All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
    • The only exception to this principle will be when the service meets all the following criteria:
      • It will be used only within the same application silo
      • There is no potential right now or in the near future for re-use of this service
      • The service has already been right-sized
      • The  Review Team has approved the exception

As previously indicated, the SOA Center of Excellence (CoE) would also have to provide guidelines on SOA processes and related technologies. This may include:

  • Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
  • Service design (SOAD, specification, Discovery Process, Taxonomy)
  • Service provisioning (SPML, contracts, SLA)
  • Service implementation development (BPEL, SOAIF)
  • Service assembly and integration (JBI, ESB)
  • Service testing
  • Service deployment (the software on the network)
  • Service discovery (UDDI, WSIL, registry)
  • Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
  • Service consumption (WSDL, BPEL)
  • Service execution  (WSDM)
  • Service versioning (UDDI, WSDL)
  • Service Management and monitoring
  • Service operation
  • Programming, granularity and abstraction

Other activities may be considered by the SOA CoE such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.

As described in the TOGAF® 9.1 Framework, the SOA CoE can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.

The Center of Excellence provides expanded opportunities for organizations to leverage and reuse service-oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under Cloud/SOA, Enterprise Architecture, Standards, TOGAF, TOGAF®, Uncategorized

Creating Reference Architecture: The Center of Excellence

By Serge Thorn, Architecting the Enterprise

This is the second installment of a three-part series discussing how to implement SOA through TOGAF®. In my first blog post I explained the concept of the Center of Excellence, and creating a vision for your organization.

The SOA Center of Excellence (CoE) will need to define a Reference Architecture for the organization.

A Reference Architecture for SOA is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers, which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.

The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.

A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.

Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.

The Open Group SOA Reference Architecture (SOA RA) standard is a good way of considering how to build systems.

The SOA CoE needs also to define the SOA lifecycle management that consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.

Simply put, without management and control, there is no SOA only an “experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.

For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.

These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment.  This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.

The “Principle of Service orientation” must exist as defined in the TOGAF® 9.1 Framework in section 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.

Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.

Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.

In the third and final installment of this series I will discuss how to relate SOA principles back to business objectives and key architecture drivers.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under Cloud/SOA, Enterprise Architecture, Standards, TOGAF, TOGAF®

Implementing SOA through TOGAF 9.1: The Center Of Excellence

By Serge Thorn, Architecting the Enterprise

This is the first installment of a three-part series discussing how to be successful in implementing an SOA initiative through TOGAF® 9.1.

Service-oriented architecture (SOA) has at times been challenged, but it is now on the verge of mainstream acceptance. It now shows maturity, success and even signs of popularity. SOA is an enterprise-scale architecture for linking resources as needed. These resources are represented as business-aligned services, which can participate and be composed in a set of choreographed processes to fulfil business needs.

In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We are now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Many Enterprise Architects are also wondering if the mobile business model will drive SOA technologies in a new direction. Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.

To be successful in implementing a SOA initiative, it is highly recommended that a company create a SOA Center of Excellence (CoE) and The Open Group clearly explains how this can be achieved through the use of TOGAF® 9.1. This article is based on the TOGAF® 9.1 Framework specification and specifically the sections 22.7.1.3 Partitions and Centers of Excellence with some additional thoughts on sections 22.7.1.1 Principle of Service-Orientation and 22.7.1.2 Governance and Support Strategy.

I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.

The figure below illustrates a SOA CoE as part of the Enterprise Architecture team with domain and solution architects as well as developers, Quality Assurances (QAs) and Business Architects and Analysts coming from a delivery organization.

Part 1 Image

Establishing a SOA Center of Excellence

The SOA CoE supports methodologies, standards, governance processes and manages a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.

According to the TOGAF 9.1 Framework specification, a successful CoE will have several key attributes, including “a clear definition of the CoE’s mission: why it exists, its scope of responsibility, and what the organization and the architecture practice should expect from the CoE.”

Define a Vision

A SOA CoE must have a purpose. What do we want to achieve? What are the problems we need to solve?

It may sound obvious, but having a blueprint for SOA is critical. It is very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.

In order to realize the vision of SOA the following topics should be addressed:

  • What to Build: A Reference Architecture
  • How to Build: Service-Oriented Modeling Method
  • Whether to build: Assessments, Roadmaps, and Maturity Evaluations
  • Guidance on Building: Architectural and Design Patterns
  • Oversight: Governance
  • How to Build: Standards and Tools

The SOA CoE would first have a vision which could be something like:

ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers.”

Then a mission statement should be communicated across the organization. Below are a few examples of mission statements:

“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”

“The mission of the CoE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The CoE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”

Define a Structure

The SOA CoE also needs to define a structure and the various interactions with the enterprise architecture team, the project management office, the business process/planning and strategy group, the product management group, etc.

The SOA CoE also needs to create a steering committee or board (which could be associated to an architecture board) to provide different types of support:

  • Architecture decision support
    • Maintain standards, templates and policies surrounding Integration and SOA
    • Participate in Integration and SOA design decisions
  • Operational support
    • Responsible for building and maintaining SOA Infrastructure
    • Purchasing registries and products to grow infrastructure
  • Development support
    • Development of administrative packages and services
    • Develop enterprise services based on strategic direction

Define Measurements

According to the TOGAF® 9.1 Framework Specification, “Clear goals for the CoE including measurements and Key Performance Indicators (KPIs). It is important to ensure that the measures and KPIs of the CoE do not drive inappropriate selection of SOA as the architecture style.”

Measurements and metrics will have to be identified. The common ones could be:

  • Service revenue
  • Service vitality
  • Ratio between services used and those created
  • Mean Time To Service Development or Service change
  • Service availability
  • Service reuse
  • Quality assurance

Define Testing Activities

As stated in the TOGAF® 9.1 Framework specification, “The CoE will provide the “litmus test” of a good service.”

Clearly comprehensive testing activities must be described by the SOA CoE. In addition to a set of defined processes related to Web Service Definition Language (WSDL) testing, functional unit testing, regression testing, security testing, interoperability testing, vulnerability testing and load, performance testing, an analysis tool suite may be used to tailor the unique testing and validation needs of Service Oriented Architectures.

This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols. A few examples include: HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.

Only by adopting a comprehensive testing stance can enterprises ensure that their SOA is robust, scalable, interoperable and secure.

  •  The CoE will disseminate the skills, experience, and capabilities of the SOA center to the rest of the architecture practice.

The Center of Excellence will promote best practices, methodologies, knowledge and pragmatic leading-edge solutions in the area of SOA to the project teams.

  •  Identify how members of the CoE, and other architecture practitioners, will be rewarded for success.

This may sounds like a good idea but I have never seen this as an applied practice.

Define a Skill Set

According to the TOGAF® 9.1 Framework specification, “Recognition that, at the start, it is unlikely the organization will have the necessary skills to create a fully functional CoE. The necessary skills and experience must be carefully identified, and where they are not present, acquired. A fundamental skill for leading practitioners within the CoE is the ability to mentor other practitioners transferring knowledge, skills, and experience.”

Competency and skills building is needed for any initiative. SOA is not just about integrating technologies and applications – it is a culture change within the enterprise, which requires IT to move from being a technology provider to a business enabler. There may be a wide range of skills required such as:

  • Enterprise Architecture
  • Value of SOA
  • Governance model for SOA
  • Business Process Management and SOA
  • Design of SOA solutions
  • Modeling
  • Technologies and standards
  • Security
  • Business communication

It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.

  • Close-out plan for when the CoE has fulfilled its purpose.

Here again, I am not sure that I have observed any SOA CoE being closed…

In the second installment of this three-part series I will discuss how the Center of Excellence defines a Reference Architecture for the organization.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under Cloud/SOA, Enterprise Architecture, Standards, TOGAF, TOGAF®

TOGAF® and BIAN – A strong proposition for the Banking Industry

By Thomas Obitz, KPMG

Earlier this year, a working group led by Paul Bonnie, ING and I published a white paper on the integration of TOGAF® and BIAN, the framework of the Banking Industry Architecture Network. Gartner even suggested that the white paper greatly aids the big problem of arriving at a consistent reference model for banks. So how does a white paper help practicing architects in banks?

Every enterprise architect knows the two most difficult questions in a complex transformation initiative: How to describe the architecture of an organization – how to break down its functions and services, and arrive at a model which makes sense to everybody; and where to get started – what needs to be done, and how do the outputs fit together?

For this second question, the industry has pretty much agreed on the answer – TOGAF. It is a best practice process with a tremendous acceptance in the market place. However, it is industry independent, and, therefore, will not provide any models describing the specifics of a bank, or even the banking IT landscape. This gap of vertical content is a significant hurdle when attempting to get architecture initiatives off the ground.

Looking at our options within The Open Group Architecture Forum to address this challenge, creating industry-specific variants of the TOGAF framework would have stretched resources a bit too thin – and so the Architecture Forum decided to find a partner to collaborate with. We found it in BIAN.

BIAN, the Banking Industry Architecture Network, publishes a reference model for the services required as building blocks in the IT landscape of a bank. Like TOGAF, it leverages the experience of its members to identify best practices, and it has the support of major banks, leading software vendors and consultancies. The current services landscape has reached a certain level of maturity, describing more than 250 services.

The white paper describes how TOGAF and BIAN fit together, and where and how to use the BIAN collateral. Adapting the frameworks together yields several key benefits:

  • The services landscape provides architects with a canvas to structure the IT landscape, to map their inherent challenges, and scope solutions quickly. Hence, it speeds up activities in the time critical mobilization phase of a transformation initiative and helps to keep momentum.
  • Once a solution has been scoped in alignment with the services landscape, vendors supporting the BIAN reference model can provide components that implement the services. Consequently, it helps in the process of vendor selection.
  • As the responsibilities of components and the business objects exchanged between them are defined, integration between components of the landscape becomes much easier, reducing integration cost and complexity.

In a recent engagement with a retail bank, I used the services landscape as the starting point for the analysis of the challenges the bank was facing and to map out potential solutions. It allowed the team to start out quickly with a structure that was accepted and natural.

So when you are looking for an approach to making a large transformation initiative fly – have a look at our paper, and use it as a tool for making your life easier. And please do give us feedback on your experiences with it via email or in the comments section of this blog post.


Thomas Obitz is a Principal Advisor with KPMG LLP in London. Building on more than 20 years of experience in the IT industry, he acts primarily as a lead architect of major initiatives, as an enterprise architect, and a business architect. He has more than 13 years of experience in the Financial Services industry, with a strong focus on Investment Banking and Capital Markets. 

1 Comment

Filed under Business Architecture, TOGAF®

ArchiMate 2.0 – Ready for the Future of Enterprise Architecture!

By Henry Franken, BIZZdesign

Models have played an important role in business for a long time. Process models, information- and data models, application landscapes, strategic models, operational models – you name it, organizations have tried it. With the rise of Enterprise Architecture (EA) as a strategic discipline for many organizations, we saw two interesting developments. First of all, organizations try to connect their models, to gain insight in the way the enterprise works from many different perspectives. Secondly, we saw the trend that models become more high-level, focusing on the essence of the organization.

These developments have led to the development of the ArchiMate® language, which allows high-level modeling within a domain, but allows modeling the relations between domains. Even more, in recognition that architecture is a communications game, a key driver for the language was to also allow for effective visualizations for key stakeholders based on solid architectural analyses.

The first edition of the ArchiMate language enabled organizations to create holistic architecture models with concepts from three domains: business, application and technology. With a handful of concepts and relations, this allowed organizations to model the relation between products and services, processes, supporting applications and information, as well as infrastructure. Having modeled this formally, organizations can do impact assessments, generate visualizations for various stakeholders and so on.

ArchiMate has recently been extended by members within the ArchiMate Forum within The Open Group), resulting in ArchiMate 2.0 – a new version of ArchiMate that is fully aligned with The Open Group Architecture Framework (TOGAF®). Two new extensions have been developed for this purpose, making sure the language now covers the entire Architecture Development Method (ADM) of TOGAF.

The new motivation extension allows organizations to graphically model the answer to the “why” question of EA: Who are key stakeholders of EA? What are their drivers? How do these drivers lead to principles and requirements that are realized in the architecture? This extension mainly aligns with the early phases of the TOGAF ADM.

The new ArchiMate 2.0 standard also has an implementation and migration extension that aligns with the later phases of the ADM. Using this extension, architects can align with project management and graphically model plateaus, projects and programs, as well as their deliverables.

One of the key strengths of ArchiMate – as well as TOGAF – is its openness – it allows practitioners worldwide to join in and help push the language forward. Indeed, we are seeing the adoption of the language, as well as certifications of practitioners grow worldwide.

The Open Group has introduced certification programs for individuals, training vendors and tool vendors, and the uptake of these programs is very successful! We are now seeing many individuals obtaining an ArchiMate 2.0 certificate, training vendors applying for training accreditation, and tool vendors implementing the ArchiMate modeling language into Enterprise Architecture modeling tools, all while  being certified by The Open Group.

With all these great developments within the last few years – fluent integration with TOGAF and a fast growing number of professionals using ArchiMate – I believe it is safe to say that with ArchiMate 2.0 you are ready for the future of Enterprise Architecture!

Henry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

4 Comments

Filed under ArchiMate®, Certifications, Enterprise Architecture, Enterprise Transformation, TOGAF®

Video Highlights Day 2 of Washington, D.C.

By The Open Group Conference Team

How can you use the tools of Enterprise Architecture and open standards to improve the capability of your company doing business? The Day 2 speakers of The Open Group Conference in Washington, D.C. addressed this question, focusing on Enterprise Transformation. Sessions included:

  • “Case Study: University Health Network (Toronto),” by Jason Uppal, chief enterprise architect at QR Systems, Inc. and winner of the 2012 Edison Award for Innovation
  • “Future Airborne Capability Environment (FACE™): Transforming the DoD Avionics Software Industry Through the Use of Open Standards,” by Judy Cerenzia, FACE™ program director at The Open Group, Kirk Avery, chief software architect at Lockheed Martin and Philip Minor, director at System of Systems of Engineering Directorate at the Office of Chief Systems Engineer, ASA(ALT)
  • “Using the TOGAF® Architecture Content Framework with the ArchiMate® Modeling Language,” by Henry Franken, CEO of BIZZdesign, and Iver Band, enterprise architect at Standard Insurance

David Lounsbury, CTO of The Open Group summarizes some of the day’s sessions:

Comments Off

Filed under ArchiMate®, Business Architecture, Certifications, Conference, Cybersecurity, Enterprise Architecture, Enterprise Transformation, FACE™, Information security, TOGAF®, Uncategorized

Summer in the Capitol – Looking Back at The Open Group Conference in Washington, D.C.

By Jim Hietala, The Open Group

This past week in Washington D.C., The Open Group held our Q3 conference. The theme for the event was “Cybersecurity – Defend Critical Assets and Secure the Global Supply Chain,” and the conference featured a number of thought-provoking speakers and presentations.

Cybersecurity is at a critical juncture, and conference speakers highlighted the threat and attack reality and described industry efforts to move forward in important areas. The conference also featured a new capability, as several of the events were Livestreamed to the Internet.

For those who did not make the event, here’s a summary of a few of the key presentations, as well as what The Open Group is doing in these areas.

Joel Brenner, attorney with Cooley, was our first keynote. Joel’s presentation was titled, “Turning Us Inside-Out: Crime and Economic Espionage on our Networks,” The talk mirrored his recent book, “America the Vulnerable: Inside the New Threat Matrix of Digital Espionage, Crime, and Warfare,” and Joel talked about current threats to critical infrastructure, attack trends and challenges in securing information. Joel’s presentation was a wakeup call to the very real issues of IP theft and identity theft. Beyond describing the threat and attack landscape, Joel discussed some of the management challenges related to ownership of the problem, namely that the different stakeholders in addressing cybersecurity in companies, including legal, technical, management and HR, all tend to think that this is someone else’s problem. Joel stated the need for policy spanning the entire organization to fully address the problem.

Kristin Baldwin, principal deputy, systems engineering, Office of the Assistant Secretary of Defense, Research and Engineering, described the U.S. Department of Defense (DoD) trusted defense systems strategy and challenges, including requirements to secure their multi-tiered supply chain. She also talked about how the acquisition landscape has changed over the past few years. In addition, for all programs the DoD now requires the creation of a program protection plan, which is the single focal point for security activities on the program. Kristin’s takeaways included needing a holistic approach to security, focusing attention on the threat, and avoiding risk exposure from gaps and seams. DoD’s Trusted Defense Systems Strategy provides an overarching framework for trusted systems. Stakeholder integration with acquisition, intelligence, engineering, industry and research communities is key to success. Systems engineering brings these stakeholders, risk trades, policy and design decisions together. Kristin also stressed the importance of informing leadership early and providing programs with risk-based options.

Dr. Ron Ross of NIST presented a perfect storm of proliferation of information systems and networks, increasing sophistication of threat, resulting in an increasing number of penetrations of information systems in the public and private sectors potentially affecting security and privacy. He proposed a need an integrated project team approach to information security. Dr. Ross also provided an overview of the changes coming in NIST SP 800-53, version 4, which is presently available in draft form. He also advocated a dual protection strategy approach involving traditional controls at network perimeters that assumes attackers outside of organizational networks, as well as agile defenses, are already inside the perimeter. The objective of agile defenses is to enable operation while under attack and to minimize response times to ongoing attacks. This new approach mirrors thinking from the Jericho Forum and others on de-perimeterization and security and is very welcome.

The Open Group Trusted Technology Forum provided a panel discussion on supply chain security issues and the approach that the forum is taking towards addressing issues relating to taint and counterfeit in products. The panel included Andras Szakal of IBM, Edna Conway of Cisco and Dan Reddy of EMC, as well as Dave Lounsbury, CTO of The Open Group. OTTF continues to make great progress in the area of supply chain security, having published a snapshot of the Open Trusted Technology Provider Framework, working to create a conformance program, and in working to harmonize with other standards activities.

Dave Hornford, partner at Conexiam and chair of The Open Group Architecture Forum, provided a thought provoking presentation titled, “Secure Business Architecture, or just Security Architecture?” Dave’s talk described the problems in approaches that are purely focused on securing against threats and brought forth the idea that focusing on secure business architecture was a better methodology for ensuring that stakeholders had visibility into risks and benefits.

Geoff Besko, CEO of Seccuris and co-leader of the security integration project for the next version of TOGAF®, delivered a presentation that looked at risk from a positive and negative view. He recognized that senior management frequently have a view of risk embracing as taking risk with am eye on business gains if revenue/market share/profitability, while security practitioners tend to focus on risk as something that is to be mitigated. Finding common ground is key here.

Katie Lewin, who is responsible for the GSA FedRAMP program, provided an overview of the program, and how it is helping raise the bar for federal agency use of secure Cloud Computing.

The conference also featured a workshop on security automation, which featured presentations on a number of standards efforts in this area, including on SCAP, O-ACEML from The Open Group, MILE, NEA, AVOS and SACM. One conclusion from the workshop was that there’s presently a gap and a need for a higher level security automation architecture encompassing the many lower level protocols and standards that exist in the security automation area.

In addition to the public conference, a number of forums of The Open Group met in working sessions to advance their work in the Capitol. These included:

All in all, the conference clarified the magnitude of the cybersecurity threat, and the importance of initiatives from The Open Group and elsewhere to make progress on real solutions.

Join us at our next conference in Barcelona on October 22-25!

Jim Hietala, CISSP, GSEC, is the Vice President, Security for The Open Group, where he manages all IT security and risk management programs and standards activities. He participates in the SANS Analyst/Expert program and has also published numerous articles on information security, risk management, and compliance topics in publications including The ISSA Journal, Bank Accounting & Finance, Risk Factor, SC Magazine, and others.

Comments Off

Filed under Conference, Cybersecurity, Enterprise Architecture, Information security, OTTF, Security Architecture, Supply chain risk, TOGAF®

TOGAF® 9 Certification Growth – Number of Individuals Certified Doubles in the Last 12 Months – Now Over 14,800

By Andrew Josey, The Open Group

The number of individuals certified in the TOGAF® 9 certification program as of July 1st 2012 is 14,851. This represents a doubling of the number of individuals certified in the last 12 months with 7,640 new certifications during that period. The latest statistics show that certifications are now growing at two thousand individuals per quarter.

TOGAF is being adopted globally. The top five countries include the UK, Netherlands, USA, Australia and India.

Here is a list of individuals certifications among the top 20 countries, as of July 2012

Rank # Individuals Country Percentage
1 2444 UK 16.2
2 1916 USA 12.8
3 1607 Netherlands 10.8
4 1093 Australia 7.3
5 913 India 6.1
6 705 Canada 4.7
7 637 South Africa 4.2
8 524 Finland 3.5
9 517 France 3.4
10 434 China 2.8
11 379 Norway 2.5%
12 344 Sweden 2.3%
13 280 Germany 1.8%
14 271 Belgium 1.8%
15 244 United Arab Emirates 1.6%
16 224 Denmark 1.5%
17 209 Japan 1.4%
18 176 New Zealand 1.1%
19 173 Saudi Arabia 1.1%
20 136 Czech Republic 0.9%

There are 43 TOGAF 9 training partners worldwide and 48 accredited TOGAF 9 courses.  More information on TOGAF 9 Certification, including the official accredited training course calendar and a directory of certified people and, can be found on The Open Group website at: http://www.opengroup.org/togaf9/cert/.

(This blog post was edited on August 16)

Andrew Josey is Director of Standards within The Open Group. He is currently managing the standards process for The Open Group, and has recently led the standards development projects for TOGAF 9.1, ArchiMate 2.0, IEEE Std 1003.1-2008 (POSIX), and the core specifications of the Single UNIX Specification, Version 4. Previously, he has led the development and operation of many of The Open Group certification development projects, including industry-wide certification programs for the UNIX system, the Linux Standard Base, TOGAF, and IEEE POSIX. He is a member of the IEEE, USENIX, UKUUG, and the Association of Enterprise Architects.

14 Comments

Filed under Certifications, Enterprise Architecture, TOGAF®

Leveraging TOGAF to Deliver DoDAF Capabilities

By Chris Armstrong, Armstrong Process Group

In today’s environment of competing priorities and constrained resources, companies and government agencies are in even greater need to understand how to balance those priorities, leverage existing investments and align their critical resources to realize their business strategy. Sound appealing? It turns out that this is the fundamental goal of establishing an Enterprise Architecture (EA) capability. In fact, we have seen some of our clients position EA as the Enterprise Decision Support capability – that is, providing an architecture-grounded, fact-based approach to making business and IT decisions.

Many government agencies and contractors have been playing the EA game for some time — often in the context of mandatory compliance with architecture frameworks, such as the Federal Enterprise Architecture (FEA) and the Department of Defense Architecture Framework (DoDAF). These frameworks often focus significantly on taxonomies and reference models that organizations are required to use when describing their current state and their vision of a future state. We’re seeing a new breed of organizations that are looking past contractual compliance and want to exploit the business transformation dimension of EA.

In the Department of Defense (DoD) world, this is in part due to the new “capability driven” aspect of DoDAF version 2.0, where an organization aligns its architecture to a set of capabilities that are relevant to its mission. The addition of the Capability Viewpoint (CV) in DoDAF 2 enables organizations to describe their capability requirements and how their organization supports and delivers those capabilities. The CV also provides models for representing capability gaps and how new capabilities are going to be deployed over time and managed in the context of an overall capability portfolio.

Another critical difference in DoDAF 2 is the principle of “fit-for-purpose,” which allows organizations to select which architecture viewpoints and models to develop based on mission/program requirements and organizational context. One fundamental consequence of this is that an organization is no longer required to create all the models for each DoDAF viewpoint. They are to select the models and viewpoints that are relevant to developing and deploying their new, evolved capabilities.

While DoDAF 2 does provide some brief guidance on how to build architecture descriptions and subsequently leverage them for capability deployment and management, many organizations are seeking a more well-defined set of techniques and methods based on industry standard best practices.

This is where the effectiveness of DoDAF 2 can be significantly enhanced by integrating it with The Open Group Architecture Framework (TOGAF®) version 9.1, in particular the TOGAF Architecture Development Method (ADM). The ADM not only describes how to develop descriptions of the baseline and target architectures, but also provides considerable guidance on how to establish an EA capability and performing architecture roadmapping and migration planning. Most important, the TOGAF ADM describes how to drive the realization of the target architecture through integration with the systems engineering and solution delivery lifecycles. Lastly, TOGAF describes how to sustain an EA capability through the operation of a governance framework to manage the evolution of the architecture. In a nutshell, DoDAF 2 provides a common vocabulary for architecture content, while TOGAF provides a common vocabulary for developing and using that content.

I hope that those of you in the Washington, D.C. area will join me at The Open Group conference next week, where we’ll continue the discussion of how to deliver DoDAF capabilities using TOGAF. For those of you who can’t make it, I’m pleased to announce that The Open Group will also be delivering a Livestream of my presentation (free of charge) on Monday, July 16 at 2:45 p.m. ET.

Hope to see you there!

Chris Armstrong, president of Armstrong Process Group, Inc., is an internationally recognized thought leader in Enterprise Architecture, formal modeling, process improvement, systems and software engineering, requirements management, and iterative and agile development. Chris represents APG at The Open Group, the Object Management Group and the Eclipse Foundation.

 

2 Comments

Filed under Conference, Enterprise Architecture, TOGAF®

Adapting to an eBook World

By Chris Harding, The Open Group

Have you ever wanted to read something to prepare for a meeting while traveling, but  been frustrated by the difficulty of managing paper or a bulky PC? Travelers who read for pleasure have found eBooks a very convenient way to meet their needs. This format is now becoming available for select Open Group standards and guides, so that you can read them more easily when “on the road.”

The eBook format allows the device to lay out the text, rather than trying to fit pre-formatted pages to devices of all shapes and size (It is based on HTML). This makes reading an eBook a much easier and more pleasant experience than trying to read a static format such as PDF on a device where the page doesn’t fit.

There are portable electronic devices designed primarily for the purpose of reading digital books – the Amazon Kindle is the best known – but eBooks can also be read on tablets, mobile phones (on which the quality can be surprisingly good) and, of course, on laptops, using free-to-download software apps. The eBook readers are, essentially, small-sized special-purpose tablets with superb text display quality and – a big advantage on a long flight – batteries that can go weeks rather than hours without re-charging. As the quality and battery life of tablets continues to improve, they are starting to overtake specialized reader devices, which have one major disadvantage: a lack of standardization.

There are a number of different eBook formats, the most prominent being EPUB, an open standard created by the International Digital Publishing Forum, KF8, the proprietary format used by Amazon Kindle, and Mobipocket, a format that the Kindle will also handle (There is an excellent Wikipedia article on eBook formats, see http://en.wikipedia.org/wiki/Comparison_of_e-book_formats). You can read any of the most popular formats on a tablet (or PC, Mac, iPhone or Android device) using a software app, but you are likely to find that a specialized reader device is limited in the formats that it can handle.

Many of the Open Group SOA Standards and Guides are now freely available in the EPUB and Mobipocket formats from The Open Group bookstore. See http://soa-standards.opengroup.org/post/eBook-Versions-of-SOA-Standards-and-Guides-5884765 for the current list. We are hoping to make all our new SOA standards and guides available in this way, and also some Open Group publications on Cloud Computing. EPUB versions of TOGAF® Version 9.1, the TOGAF 9.1 Pocket Guide and the TOGAF 9 study guides are available for purchase from The Open Group’s official publisher, Van Haren. The SOA and the TOGAF EPUBS can be obtained from The Open Group bookstore at http://www.opengroup.org/bookstore/catalog .

Thirty years ago, I used to attend meetings of the CCITT (now the ITU-T) in Geneva. The trolleys that were pushed around the UN building, piled high with working documents for distribution to delegates, were an impressive sight, but the sheer weight of paper that had to be carried to and from the meetings was a real problem. Laptops with Internet access have removed the need to carry documents. Now, eBooks are making it easy to read them while traveling!

We have started to make eBook versions of our standards and guides available and are still exploring the possibilities. We’d love to hear your thoughts on what will or won’t work, and what will work best.  Please feel free to share your ideas in the comments section below.

Andrew Josey, director of standards at The Open Group, contributed to the technical aspects of this blog post. 

Dr. Chris Harding is Director for Interoperability and SOA at The Open Group. He has been with The Open Group for more than ten years, and is currently responsible for managing and supporting its work on interoperability, including SOA and interoperability aspects of Cloud Computing. He is a member of the BCS, the IEEE and the AEA, and is a certified TOGAF practitioner.

Comments Off

Filed under Cloud/SOA, TOGAF®

Learn How Enterprise Architects Can Better Relate TOGAF and DoDAF to Bring Best IT Practices to Defense Contracts

By Dana Gardner, Interarbor Solutions

This BriefingsDirect thought leadership interview comes in conjunction with The Open Group Conference in Washington, D.C., beginning July 16. The conference will focus on how Enterprise Architecture (EA), enterprise transformation, and securing global supply chains.

We’re joined by one of the main speakers at the July 16 conference, Chris Armstrong, President of Armstrong Process Group, to examine how governments in particular are using various frameworks to improve their architectural planning and IT implementations.

Armstrong is an internationally recognized thought leader in EA, formal modeling, process improvement, systems and software engineering, requirements management, and iterative and agile development.

He represents the Armstrong Process Group at the Open Group, the Object Management Group (OMG), and Eclipse Foundation. Armstrong also co-chairs The Open Group Architectural Framework (TOGAF®), and Model Driven Architecture (MDA) process modeling efforts, and also the TOGAF 9 Tool Certification program, all at The Open Group.

At the conference, Armstrong will examine the use of TOGAF 9 to deliver Department of Defense (DoD) Architecture Framework or DoDAF 2 capabilities. And in doing so, we’ll discuss how to use TOGAF architecture development methods to drive the development and use of DoDAF 2 architectures for delivering new mission and program capabilities. His presentation will also be Livestreamed free from The Open Group Conference. The full podcast can be found here.

Here are some excerpts:

Gardner: TOGAF and DoDAF, where have they been? Where are they going? And why do they need to relate to one another more these days?

Armstrong: TOGAF [forms] a set of essential components for establishing and operating an EA capability within an organization. And it contains three of the four key components of any EA.

First, the method by which EA work is done, including how it touches other life cycles within the organization and how it’s governed and managed. Then, there’s a skills framework that talks about the skills and experiences that the individual practitioners must have in order to participate in the EA work. Then, there’s a taxonomy framework that describes the semantics and form of the deliverables and the knowledge that the EA function is trying to manage.

One-stop shop

One of the great things that TOGAF has going for it is that, on the one hand, it’s designed to be a one-stop shop — namely providing everything that a end-user organization might need to establish an EA practice. But it does acknowledge that there are other components, predominantly in the various taxonomies and reference models, that various end-user organizations may want to substitute or augment.

It turns out that TOGAF has a nice synergy with other taxonomies, such as DoDAF, as it provides the backdrop for how to establish the overall EA capability, how to exploit it, and put it into practice to deliver new business capabilities.

Frameworks, such as DoDAF, focus predominantly on the taxonomy, mainly the kinds of things we’re keeping track of, the semantics relationships, and perhaps some formalism on how they’re structured. There’s a little bit of method guidance within DoDAF, but not a lot. So we see the marriage of the two as a natural synergy.

Gardner: So their complementary natures allows for more particulars on the defense side, but the overall TOGAF looks at the implementation method and skills for how this works best. Is this something new, or are we just learning to do it better?

Armstrong: I think we’re seeing the state of industry advance and looking at trying to have the federal government, both United States and abroad, embrace global industry standards for EA work. Historically, particularly in the US government, a lot of defense agencies and their contractors have often been focusing on a minimalistic compliance perspective with respect to DoDAF. In order to get paid for this work or be authorized to do this work, one of our requirements is we must produce DoDAF.

People are doing that because they’ve been commanded to do it. We’re seeing a new level of awareness. There’s some synergy with what’s going on in the DoDAF space, particularly as it relates to migrating from DoDAF 1.5 to DoDAF 2.

Agencies need some method and technique guidance on exactly how to come up with those particular viewpoints that are going to be most relevant, and how to exploit what DoDAF has to offer, in a way that advances the business as opposed to just solely being to conforming or compliant?

Gardner: Have there been hurdles, perhaps culturally, because of the landscape of these different companies and their inability to have that boundary-less interaction. What’s been the hurdle? What’s prevented this from being more beneficial at that higher level?

Armstrong: Probably overall organizational and practitioner maturity. There certainly are a lot of very skilled organizations and individuals out there. However, we’re trying to get them all lined up with the best practice for establishing an EA capability and then operating it and using it to a business strategic advantage, something that TOGAF defines very nicely and which the DoDAF taxonomy and work products hold in very effectively.

Gardner: Help me understand, Chris. Is this discussion that you’ll be delivering on July 16 primarily for TOGAF people to better understand how to implement vis-à-vis, DoDAF, is this the other direction, or is it a two-way street?

Two-way street

Armstrong: It’s a two-way street. One of the big things that particularly the DoD space has going for it is that there’s quite a bit of maturity in the notion of formally specified models, as DoDAF describes them, and the various views that DoDAF includes.

We’d like to think that, because of that maturity, the general TOGAF community can glean a lot of benefit from the experience they’ve had. What does it take to capture these architecture descriptions, some of the finer points about managing some of those assets. People within the TOGAF general community are always looking for case studies and best practices that demonstrate to them that what other people are doing is something that they can do as well.

We also think that the federal agency community also has a lot to glean from this. Again, we’re trying to get some convergence on standard methods and techniques, so that they can more easily have resources join their teams and immediately be productive and add value to their projects, because they’re all based on a standard EA method and framework.

One of the major changes between DoDAF 1 and DoDAF 2 is the focusing on fitness for purpose. In the past, a lot of organizations felt that it was their obligation to describe all architecture viewpoints that DoDAF suggests without necessarily taking a step back and saying, “Why would I want to do that?”

So it’s trying to make the agencies think more critically about how they can be the most agile, mainly what’s the least amount of architecture description that we can invest and that has the greatest possible value. Organizations now have the discretion to determine what fitness for purpose is.

Then, there’s the whole idea in DoDAF 2, that the architecture is supposed to be capability-driven. That is, you’re not just describing architecture, because you have some tools that happened to be DoDAF conforming, but there is a new business capability that you’re trying to inject into the organization through capability-based transformation, which is going to involve people, process, and tools.

One of the nice things that TOGAF’s architecture development method has to offer is a well-defined set of activities and best practices for deciding how you determine what those capabilities are and how you engage your stakeholders to really help collect the requirements for what fit for purpose means.

Gardner: As with the private sector, it seems that everyone needs to move faster. I see you’ve been working on agile development. With organizations like the OMG and Eclipse is there something that doing this well — bringing the best of TOGAF and DoDAF together — enables a greater agility and speed when it comes to completing a project?

Different perspectives

Armstrong: Absolutely. When you talk about what agile means to the general community, you may get a lot of different perspectives and a lot of different answers. Ultimately, we at APG feel that agility is fundamentally about how well your organization responds to change.

If you take a step back, that’s really what we think is the fundamental litmus test of the goodness of an architecture. Whether it’s an EA, a segment architecture, or a system architecture, the architects need to think thoughtfully and considerately about what things are almost certainly going to happen in the near future. I need to anticipate, and be able to work these into my architecture in such a way that when these changes occur, the architecture can respond in a timely, relevant fashion.

We feel that, while a lot of people think that agile is just a pseudonym for not planning, not making commitments, going around in circles forever, we call that chaos, another five letter word. But agile in our experience really demands rigor, and discipline.

Of course, a lot of the culture of the DoD brings that rigor and discipline to it, but also the experience that that community has had, in particular, of formally modeling architecture description. That sets up those government agencies to act agilely much more than others.

Gardner: Do you know of anyone that has done it successfully or is in the process? Even if you can’t name them, perhaps you can describe how something like this works?

Armstrong: First, there has been some great work done by the MITRE organization through their work in collaboration at The Open Group. They’ve written a white paper that talks about which DoDAF deliverables are likely to be useful in specific architecture development method activities. We’re going to be using that as a foundation for the talk we’re going to be giving at the conference in July.

The biggest thing that TOGAF has to offer is that a nascent organization that’s jumping into the DoDAF space may just look at it from an initial compliance perspective, saying, “We have to create an AV-1, and an OV-1, and a SvcV-5,” and so on.

Providing guidance

TOGAF will provide the guidance for what is EA. Why should I care? What kind of people do I need within my organization? What kind of skills do they need? What kind of professional certification might be appropriate to get all of the participants up on the same page, so that when we’re talking about EA, we’re all using the same language?

TOGAF also, of course, has a great emphasis on architecture governance and suggests that immediately, when you’re first propping up your EA capability, you need to put into your plan how you’re going to operate and maintain these architectural assets, once they’ve been produced, so that you can exploit them in some reuse strategy moving forward.

So, the preliminary phase of the TOGAF architecture development method provides those agencies best practices on how to get going with EA, including exactly how an organization is going to exploit what the DoDAF taxonomy framework has to offer.

Then, once an organization or a contractor is charged with doing some DoDAF work, because of a new program or a new capability, they would immediately begin executing Phase A: Architecture Vision, and follow the best practices that TOGAF has to offer.

Just what is that capability that we’re trying to describe? Who are the key stakeholders, and what are their concerns? What are their business objectives and requirements? What constraints are we going to be placed under?

Part of that is to create a high-level description of the current or baseline architecture descriptions, and then the future target state, so that all parties have at least a coarse-grained idea of kind of where we’re at right now, and what our vision is of where we want to be.

Because this is really a high level requirements and scoping set of activities, we expect that that’s going to be somewhat ambiguous. As the project unfolds, they’re going to discover details that may cause some adjustment to that final target.

Internalize best practices

So, we’re seeing defense contractors being able to internalize some of these best practices, and really be prepared for the future so that they can win the greatest amount of business and respond as rapidly and appropriately as possible, as well as how they can exploit these best practices to affect greater business transformation across their enterprises.

Gardner: We mentioned that your discussion on these issues, on July 16 will be Livestreamed for free, but you’re also doing some pre-conference and post-conference activities — webinars, and other things. Tell us how this is all coming together, and for those who are interested, how they could take advantage of all of these.

Armstrong: We’re certainly very privileged that The Open Group has offered this as opportunity to share this content with the community. On Monday, June 25, we’ll be delivering a webinar that focuses on architecture change management in the DoDAF space, particularly how an organization migrates from DoDAF 1 to DoDAF 2.

I’ll be joined by a couple of other people from APG, David Rice, one of our Principal Enterprise Architects who is a member of the DoDAF 2 Working Group, as well as J.D. Baker, who is the Co-chair of the OMG’s Analysis and Design Taskforce, and a member of the Unified Profile for DoDAF and MODAF (UPDM) work group, a specification from the OMG.

We’ll be talking about things that organizations need to think about as they migrate from DoDAF 1 to DoDAF 2. We’ll be focusing on some of the key points of the DoDAF 2 meta-model, namely the rearrangement of the architecture viewpoints and the architecture partitions and how that maps from the classical DoDAF 1.5 viewpoint, as well as focusing on this notion of capability-driven architectures and fitness for purpose.

We also have the great privilege after the conference to be delivering a follow-up webinar on implementation methods and techniques around advanced DoDAF architectures. Particularly, we’re going to take a closer look at something that some people may be interested in, namely tool interoperability and how the DoDAF meta-model offers that through what’s called the Physical Exchange Specification (PES).

We’ll be taking a look a little bit more closely at this UPDM thing I just mentioned, focusing on how we can use formal modeling languages based on OMG standards, such as UML, SysML, BPMN, and SoaML, to do very formal architectural modeling.

One of the big challenges with EA is, at the end of the day, EA comes up with a set of policies, principles, assets, and best practices that talk about how the organization needs to operate and realize new solutions within that new framework. If EA doesn’t have a hand-off to the delivery method, namely systems engineering and solution delivery, then none of this architecture stuff makes a bit of a difference.

Driving the realization

We’re going to be talking a little bit about how DoDAF-based architecture description and TOGAF would drive the realization of those capabilities through traditional systems, engineering, and software development method.

************

For more information on The Open Group’s upcoming conference in Washington, D.C., please visit: http://www.opengroup.org/dc2012

Dana Gardner is president and principal analyst at Interarbor Solutions, an enterprise IT analysis, market research, and consulting firm. Gardner, a leading identifier of software and Cloud productivity trends and new IT business growth opportunities, honed his skills and refined his insights as an industry analyst, pundit, and news editor covering the emerging software development and enterprise infrastructure arenas for the last 18 years.

Comments Off

Filed under Conference, Enterprise Architecture, Enterprise Transformation, TOGAF®

RECAP: The Open Group Brazil Conference – May 24, 2012

By Isabela Abreu, The Open Group

Under an autumn Brazilian sky, The Open Group held its first regional event in São Paulo, Brazil, and it turned out to be a great success. More than 150 people attended the conference – including Open Group platinum members (CapGemini, HP, IBM and Oracle), the Brazil chapter of the Association of Enterprise Architecture (AEA), and Brazilian organizations (Daryus, Sensedia) – displaying a robust interest for Enterprise Architecture (EA) within the world’s sixth largest economy. The Open Group also introduced its mission, vision and values to the marketplace – a working model not very familiar to the Brazilian environment.

After the 10 hour, one-day event, I’m pleased to say that The Open Group’s first formal introduction to Brazil was well received, and the organization’s mission was immediately understood!

Introduction to Brazil

The event started with a brief introduction of The Open Group by myself, Isabela Abreu, Open Group country manager of Brazil, and was followed by an impressive presentation by Allen Brown, CEO of The Open Group, on how enterprise architects hold the power to change an organization’s future, and stay ahead of competitors, by using open standards that drive business transformation.

The conference aimed to provide an overview of trending topics, such as business transformation, EA, TOGAF®, Cloud Computing, SOA and Information Security. The presentations focused on case studies, including one by Marcelo Sávio of IBM that showed how the organization has evolved through the use of EA Governance; and one by Roberto Soria of Oracle that provided an introduction to SOA Governance.

Enterprise Architecture

Moving on to architecture, Roberto Severo, president of the AEA in Brazil, pointed out why architects must join the association to transform the Brazil EA community into a strong and ethical tool for transforming EA. He also demonstrated how to align tactical decisions to strategic objectives using Cloud Computing. Then Cecilio Fraguas of CPM Braxis CapGemini provided an introduction to TOGAF®; and Courtnay Guimarães of Instisys comically evinced that although it is sometimes difficult to apply, EA is a competitive tool for investment banks

Security

On the security front, Rodrigo Antão of Apura showed the audience that our enemies know us, but we don’t know them, in a larger discussion about counter-intelligence and cybersecurity; he indicated that architects are wrong when tend to believe EA has nothing to do with Information Security. In his session titled, “OSIMM: How to Measure Success with SOA and Design the Roadmap,” Luís Moraes of Sensedia provided a good overview for architects and explained how to measure success with SOA and design roadmaps with OSIMM - a maturity model of integration services soon to become an ISO standard, based on SOA and developed by The Open Group. Finally, Alberto Favero of Ernst & Young presented the findings of the Ernst & Young 2011 Global Information Security Survey, closing the event.

Aside from the competitive raffle, the real highlight of the event happened at lunch when I noticed the networking between conference attendees. I can testify that the Brazilian EA community actively ideas, in the spirit of The Open Group!

By the end of the day, everybody returned home with new ideas and new friends. I received many inquiries on how to keep the community engaged after the conference, and I promise to keep activities up and running here, in Brazil.

Stay tuned, as we plan sending on a survey to conference attendees, as well the link to all of the presentations. Thanks to everyone who made the conference a great success!

Isabela Abreu is The Open Group country manager for Brazil. She is a member of AEA Brazil and has participated in the translation of the glossary of TOGAF® 9.1, ISO/IEC 20000:1 and ISO/IEC 20000:5 and ITIL V3 to Portuguese. Abreu has worked for itSMF Brazil, EXIN Brazil – Examination Institute for Information Science, and PATH ITTS Consultancy, and is a graduate of São Paulo University.

1 Comment

Filed under Cloud, Conference, Cybersecurity, Enterprise Architecture, TOGAF®

Cannes Conference Day 2: Proactively Engaging in the Transformation Process Paramount for Enterprise Architects

By The Open Group Conference Team

After the conference’s first night on the French Riviera, Day 2 of the Cannes Conference continued with the theme of transformation. The first plenary session led by Dr. Saeed Al Daheri, IT director of the United Arab Emirates Ministry of Foreign Affairs (MOFA), examined how one of the world’s emerging countries emphasized the alignment of IT and strategy.

MOFA wanted to increase performance by building up process, people and technology. Dr. Al Daheri was in charge of this project and decided to focus on three key initiatives: establishing EA, building IT capacity and running quick wins. MOFA wanted its Enterprise Architecture (EA) program to become central to the operation of IT and to have a mandate over all domains of the enterprise, including business strategy all the way down to business processes. EA provided the foundation to align IT and business, which was considered to be of paramount importance.

As with most major transformations within an organization, Dr. Al Daheri and his team faced several key challenges, which included leadership endorsement, recruitment and IT culture and the traditional view of IT. Through clear communication and education, the project received a top-down mandate that helped them receive buy-in from key stakeholders, which was essential for success. Regarding recruiting, the skills of an architect were hard to come by, especially one who speaks Arabic, so in order to succeed the IT department added 10 new positions to support this initiative and created a training program to develop the skill of existing staff. And finally through more proactive engagement with the rest of MOFA and by anticipating business needs and outlining clear roles and responsibilities, IT was able to work hand-in-hand with the business to achieve the ultimate goal of increased performance.

Through careful planning and proper implementation, MOFA was able to reduce vendor selection to 5 weeks, realize 26% cost savings and reduce project time by 17% – truly transformative results that were achieved through IT and business alignment.

A New Approach to EA: Less Thinking, More Doing

In the second plenary session, Peter Haviland, chief architect and head of business architecture within Ernst & Young‘s Advisory Services, along with two colleagues, Mick Adams and Garth Emrich, presented “World-Class EA 2012: Less Thinking, More Doing.” There’s a lot of talk of enterprise transformation, but how involved are enterprise architects in this process? Haviland started the presentation by asking the question, “How many architects are truly seeking out proactive opportunities?”

Haviland argued that EA is in prime position to help transform organizations through the improvement of the execution of strategy across business functions and the investment in process, tools, training and IT. But in order to do so, architects need to seek out opportunities to become a crucial part of enterprise transformation. Haviland listed out four questions that architects need to ask themselves to become more proactive.

  • What’s the context? Understanding the context of the situation is key to enabling enterprise transformation. EAs need to take a step back and look at the bigger picture, rather than purely focusing on building models. This will ensure alignment with the overall business strategy.
  • How do you flex your capability? Once you have completed your situational analysis, how can your skills translate into producing the desired results? Using your skills to help the enterprise achieve its goal of enterprise transformation will ultimately raise the visibility of EA within your organization.
  • What are the risks, opportunities and costs? E&Y recently completed a global survey that explored the top 10 risks that can be turned into opportunities, with the number one risk being regulation and compliance. It’s essential to understand the risks, opportunities and costs before embarking on enterprise transformation, for that is where the biggest gains can be realized.
  • If I’m an architect, what do I want to own? Assess the project and determine where your skill set will provide the biggest overall impact. This will allow you to provide the most value as an architect and set you up for success.

Being more proactive will help architects not only become a more integral part of your organization, but it will also establish EA as a key driver of enterprise transformation.

How to Create Value in the FACE™ of Shrinking Government Budgets

Improving performance while cutting costs – this is the mandate of most organizations these days, including governments. While budget cuts to the U.S. Department of Defense (DoD) budget require them to scale back on new platforms and funding for military technology procurements, the need for civilian safety and military performance continues to be a top priority. But how can the DoD do more with less?

Judy Cerenzia, The Open Group program director for the Future Airborne Capability Environment (FACE) Consortium, and Kirk Avery, chief software architect for Lockheed Martin Mission Systems and Sensors, addressed this question during final plenary session of the day. This session examined how FACE was able to help the DoD and the avionics industry provide complex mission capability faster in an environment of shrinking budgets.

In order to achieve this goal, FACE saw the need to transform the operating environment by developing a common operating environment (COE) to support applications across multiple DoD avionics systems – something that had never been done before. After reaching out to the DoD and other stakeholders including corporations that produce military components, FACE concluded that a successful COE would enable real time operating systems, stability, competition to prevent vendor lock-in, the ability to withstand extreme environmental conditions and a system life that spans many years.

With this in mind, FACE set out to develop a non-proprietary open environment that enabled a flexible software open systems architecture. The hard work of the consortium, which was established in June 2010, resulted in the creation of the FACE Business Guide and the recently released FACE Technical Standard. Both deliverables have helped the DoD and the avionics industry achieve their goal of providing complex mission capability faster with less budget and realize other benefits that include:

  • Reduction of time to field capabilities of new technologies
  • Interoperable software components within the environment
  • Portability of software components across an avionics platforms
  • Reduction of integration effort, schedule and cost
  • Enablement of truly open software components in existing and future avionics systems

Transformation within the government is quite an accomplishment, and FACE is looking to further develop common operating environments through continued collaboration between government and the avionics industry.

A Day 2 video recap by Peter Haviland will be published soon. To view the full list of conference sessions, please visit http://www3.opengroup.org/cannes2012

1 Comment

Filed under Conference, Enterprise Architecture, Enterprise Transformation, FACE™, TOGAF®

The Open Group Brings the Cloud to Cannes (Well, Let’s Hope That’s Only Metaphorically the Case)

By Stuart Boardman, KPN 

On Wednesday, April 25 at The Open Group Cannes Conference, we have a whole stream of sessions that will discuss Cloud Computing. There’s a whole bunch of interesting presentations on the program but one of the things that struck me in particular is how many of them are dealing with Cloud as an ecosystem. As a member of The Open Group’s Cloud Work Group, this is not a huge surprise for me (we do tell each other what we’re working on!), but it also happens to be a major preoccupation of mine at the moment, so I tend to notice occurrences of the word “ecosystem” or of related concepts. Outside of The Open Group in the wider Enterprise Architecture community, there’s more and more being written about ecosystems. The topic was the focus of my last Open Group blog .

On Wednesday, you’ll hear Boeing’s TJ Virdi and Kevin Sevigny with Conexiam Solutions talking about ecosystems in the context of Cloud and TOGAF. They’ll be talking about “how the Cloud Ecosystem impacts Enterprise Architecture,” which will include “an overview of how to use TOGAF to develop an Enterprise Architecture for the Cloud ecosystem.”  This work comes out of the Using TOGAF for Cloud Ecosystem project (TOGAF-CE), which they co-chair. Capgemini’s Mark Skilton kicks off the day with a session called “Selecting and Delivering Successful Cloud Products and Services.” If you’re wondering what that has to do with ecosystems, Mark pointed out to me that  “the ecosystem in that sense is business technology dynamics and the structural, trust models that….” – well I won’t spoil it – come along and hear a nice business take on the subject. In fact, I wonder who on that Wednesday won’t be talking in one way or another about ecosystems. Take a look at the agenda for yourself.

By the way, apart from the TOGAF-CE project, several other current Open Group projects deal with ecosystems. The Cloud Interaction Ecosystem Language (CIEL) project is developing a visual language for Cloud ecosystems and then there’s the Cloud Interoperability and Portability project, which inevitably has to concern itself with ecosystems. So it’s clearly a significant concept for people to be thinking about.

In my own presentation I’ll be zooming in on Social Business as a Cloud-like phenomenon. “What has that to do with Cloud?” you might be asking. Well quite a lot actually. Technologically most social business tools have a Cloud delivery model. But far more importantly a social business involves interaction across parties who may not have any formal relationship (e.g. provider to not-yet customer or to potential partner) or where the formal aspect of their relationship doesn’t include the social business part (e.g. engaging a customer in a co-creation initiative). In some forms it’s really an extended enterprise. So even if there were no computing involved, the relationship has the same Cloud-like, loosely coupled, service oriented nature. And of course there is a lot of information technology involved. Moreover, most of the interaction takes place over Internet- based services. In a successful social business these will not be the proprietary services of the enterprise but the public services of one or more market leading provider, because that’s where your customers and partners interact. Or to put it another way, you don’t engage your customers by making them come to you but by going to them.

I don’t want to stretch this too far. The point here is not to insist that Social Business is a form of Cloud but rather that they have comparable types of ecosystem and that they are therefore amenable to similar analysis methods. There are of course essential parts of Cloud that are purely the business of the provider and are quite irrelevant to the ecosystem (the ecosystem only cares about what they deliver). Interestingly one can’t really say that about social business – that really is all about the ecosystem. It may not matter whether we think the IT underlying social business is really Cloud computing but it most certainly is part of the ecosystem.

In my presentation, I’ll be looking at techniques we can use to help us understand what’s going on in an ecosystem and how changes in one place can have unexpected effects elsewhere – if we don’t understand it properly. My focus is one part of the whole body of work that needs to be done. There is work being done on how we can capture the essence of a Cloud ecosystem (CIEL). There is work being done on how we can use TOGAF to help us describe the architecture of a Cloud ecosystem (TOGAF-CE). There is work being done on how to model ecosystem behavior in general (me and others). And there’s work being done in many places on how ecosystem participants can interoperate. At some point we’ll need to bring all this together but for now, as long as we all keep talking to each other, each of the focus areas will enrich the others. In fact I think it’s too early to try to construct some kind of grand unified theory out of it all. We’d just produce something overly complex that no one knew how to use. I hope that TOGAF Next will give us a home for some of this – not in core TOGAF but as part of the overall guidance – because enterprises are more and more drawn into and dependent upon their surrounding ecosystems and have an increasing need to understand them. And Cloud is accelerating that process.

You can expect a lot of interesting insights on Wednesday, April 25. Come along and please challenge the presenters, because we too have a lot to learn.

Stuart Boardman is a Senior Business Consultant with KPN where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity. 

Comments Off

Filed under Cloud, Conference, Enterprise Architecture, TOGAF®

Part 3 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

By Serge Thorn, Architecting the Enterprise

This is the third and final post in a three-part series by Serge Thorn. For more in this series, please see Part One and Part Two.

Value Management uses a combination of concepts and methods to create sustainable value for both organizations and their stakeholders. Some tools and techniques are specific to Value Management and others are generic tools that many organizations and individuals use. There exist many Value Management techniques such as cost-benefits analysis, SWOT analysis, value analysis, Pareto analysis, objectives hierarchy, function analysis system technique (FAST), and more…

The one I suggest to illustrate is close to the objectives hierarchy technique, which is a diagrammatic process for identifying objectives in a hierarchical manner and often used in conjunction with business functions. Close, because I will use a combination of the TOGAF® 9.1 metamodel with the ArchiMate® 2.0 Business Layer, Application Layer and Motivation Extensions Metamodels, consider core entities such as value, business goals, objectives, business processes and functions, business and application services, application functions and components. This approach was inspired by the presentation by Michael van den Dungen and Arjan Visser at The Open Group Conference in Amsterdam 2010, and here I’m also adding some ArchiMate 2.0 concepts.

First, the entities from the TOGAF 9.1 metamodel:

Then I will consider the entities from ArchiMate 2.0. Some may be identical to TOGAF 9.1. In the Business Layer, one key concept will obviously be the value. In this case I will consider the product (“A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers” according to ArchiMate 2.0), as the Enterprise Architecture program. In addition to that, I would refer to business services, functions, and processes.

In the Motivation Extension Metamodel, the goals. The objective entity in TOGAF 9.1 can also be represented using the concept of “goal.”

And in the Application Layer Metamodel, application services, functions, and components.

It is important to mention that when we deliver a value proposition, we must demonstrate to the business where the benefits will be with concrete examples. For example: the business sees Operational Excellence and Customer Intimacy as key drivers, and soon you will realize that BPM suites or CRM could support the business goals. These are the reasons why we consider the Application Layer Metamodel.

We could then use a combination of the ArchiMate 2.0 viewpoints such as: Stakeholder Viewpoint, Goal Realization Viewpoint, Motivation Viewpoint, or some other viewpoints to demonstrate the value of Enterprise Architecture for a specific business transformation program (or any other strategic initiative).

To be mentioned that the concept of benefit does not exist in any of the metamodels.

I have added the concept as an extension to ArchiMate in the following diagram which is the mapping of the value to a program related to the “improvement of customers’ relationships.” I also have intentionally limited the number of concepts or entities, such as processes, application services or measures.

Using these ArchiMate 2.0 modelling techniques can demonstrate to your stakeholders the value proposition for a business program, supported by an Enterprise Architecture initiative.

As a real example, if the expected key business benefit is operational excellence through process controls, which would represent a goal, you could present such a high level diagram to explain why application components like a BPM Suite could help (detecting fraud and errors, embedding preventive controls, continuously auditing and monitoring processes, and more).

There is definitely not a single way of demonstrating the value of Enterprise Architecture and you probably will have to adapt the process and the way you will present that value to all companies you will be working with. Without a doubt Enterprise Architecture contributes to the success of an organization and brings numerous benefits, but very often it needs to be able to demonstrate that value. Using some techniques as described previously will help to justify such an initiative.

The next steps will be the development of measures, metrics and KPIs to continuously monitor that value proposition.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, TOGAF®

Part 2 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

By Serge Thorn, Architecting the Enterprise

This is the second post in a three-part series by Serge Thorn.

Continuing from Part One of this series, here are more examples of what an enterprise cannot achieve without Enterprise Architecture:

Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems

Cost avoidance can be achieved by identifying overlapping functional scope of two or more proposed projects in an organization or the potential cost savings of IT support by standardizing on one solution.

Consolidation can happen at various levels for architectures — for shared enterprise services, applications and information, for technologies and even data centers.

This could involve consolidating the number of database servers, application or web servers and storage devices, consolidating redundant security platforms, or adopting virtualization, grid computing and related consolidation initiatives. Consolidation may be a by-product of another technology transformation or it may be the driver of these transformations.

Whatever motivates the change, the key is to be in alignment, once again, with the overall business strategy. Enterprise architects understand where the business is going, so they can pick the appropriate consolidation strategy. Rationalization, standardization and consolidation processes helps organizations understand their current enterprise maturity level and move forward on the appropriate roadmap.

More spending on innovation

Enterprise Architecture should serve as a driver of innovation. Innovation is highly important when developing a target Enterprise Architecture and in realizing the organization’s strategic goals and objectives. For example, it may help to connect the dots between business requirements and the new approaches SOA and cloud services can deliver.

Enabling strategic business goals via better operational excellence

Building Enterprise Architecture defines the structure and operation of an organization. The intent of Enterprise Architecture is to determine how an organization can most effectively achieve its current and future objectives. It must be designed to support an organization’s specific business strategies.

Jeanne W. Ross, Peter Weill, David C. Robertson in “Enterprise Architecture as Strategy: Creating a Foundation for Business” wrote “Companies with more-mature architectures reported greater success in achieving strategic goals” (p. 89). “This included better operational excellence, more customer intimacy, and greater product leadership” (p. 100).

Customer intimacy

Enterprises that are customer focused and aim to provide solutions for their customers should design their business model, IT systems and operational activities to support this strategy at the process level. This involves the selection of one or few high-value customer niches, followed by an obsessive effort at getting to know these customers in detail.

Greater product leadership

This approach enabled by Enterprise Architecture is dedicated to providing the best possible products from the perspective of the features and benefits offered to the customer. It is the basic philosophy about products that push performance boundaries. Products or services delivered by the business will be refined by leveraging IT to do the end customer’s job better. This will be accomplished by the delivery of new business capabilities (e.g. on-line websites, BI, etc.).

Comply with regulatory requirements

Enterprise Architecture helps companies to know and represent their processes and systems and how they correlate. This is fundamental for risk management and managing regulation requirements, such as those derived from Sarbanes-Oxley, COSO, HIPAA, etc.

This list could be continued as there are many other reasons why Enterprise Architecture brings benefits to organizations. Once your benefits have been documented you could also consider some value management techniques. TOGAF® 9.1 refers in the Architecture Vision phase to a target value proposition for a specific project.  In the next blog, we’ll address the issue of applying the value proposition to the Enterprise Architecture initiative as a whole.

The third and final part of this blog series will discuss value management. 

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

2 Comments

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, TOGAF®

Part 1 of 3: Building an Enterprise Architecture Value Proposition Using TOGAF® 9.1. and ArchiMate® 2.0

By Serge Thorn, Architecting the Enterprise

This is the first post in a three-part series by Serge Thorn. 

When introducing Enterprise Architecture as a program or initiative, it is regularly done from an IT perspective rarely considering what the costs will be and if there will be any return on investment. This presents a particular challenge to Enterprise Architecture.

Generally speaking, IT departments have all sorts of criteria to justify projects and measure their performance. They use measurements, metrics and KPIs. Going to the solution level, they commonly use indicators such as percentage uptime for systems from the system management team, error rates for applications from the development support team or number of calls resolved on the first call from the service desk, etc. These KPIs usually are defined at an early stage and very often delivered in dashboards from various support applications.

On the other hand, it is much more difficult to define and implement a quantifiable measure for Enterprise Architecture. Many activities introduced with appropriate governance will enhance the quality of the delivered products and services, but it still will be a challenge to attribute results to the quality of Enterprise Architecture efforts.

This being said, Enterprise Architects should be able to define and justify the benefits of their activities to their stakeholders, and to help executives understand how Enterprise Architecture will contribute to the primary value-adding objectives and processes, before starting the voyage. The more it is described and understood, the more the Enterprise Architecture team will gain support from the management. There are plenty of contributions that Enterprise Architecture brings and they will have to be documented and presented at an early stage.

There won’t be just one single answer to demonstrate the value of an Enterprise Architecture but there seems to be a common pattern when considering feedback from various companies I have worked with.

Without Enterprise Architecture you can probably NOT fully achieve:

IT alignment with the business goals

As an example among others, the problem with most IT plans is that they do not indicate what the business value is and what strategic or tactical business benefit the organization is planning to achieve. The simple matter is that any IT plan needs also to have a business metric, not only an IT metric of delivery. Another aspect is the ability to create and share a common vision of the future shared by the business and IT communities.

Integration

With the rapid pace of change in business environment, the need to transform organizations into agile enterprises that can respond quickly to change has never been greater. Methodologies and computer technologies are needed to enable rapid business and system change. The solution also lies in enterprise integration (both business and technology integration).

For business integration, we use Enterprise Architecture methodologies and frameworks to integrate functions, processes, data, locations, people, events and business plans throughout an organization. Specifically, the unification and integration of business processes and data across the enterprise and potential linkage with external partners become more and more important.

To also have technology integration, we may use enterprise portals, enterprise application integration (EAI/ESB), web services, service-oriented architecture (SOA), business process management (BPM) and try to lower the number of interfaces.

Change management

In recent years the scope of Enterprise Architecture has expanded beyond the IT domain and enterprise architects are increasingly taking on broader roles relating to organizational strategy and change management. Frameworks such as TOGAF® 9.1 include processes and tools for managing both the business/people and the technology sides of an organization. Enterprise Architecture supports the creation of changes related to the various architecture domains, evaluating the impact on the enterprise, taking into account risk management, financial aspects (cost/benefit analysis), and most importantly ensuring alignment with business goals and objectives. Enterprise Architecture value is essentially tied to its ability to help companies to deal with complexity and changes.

Reduced time to market and increased IT responsiveness

Enterprise Architecture should reduce systems development, applications generation and modernization timeframes for legacy systems. It should also decrease resource requirements. All of this can be accomplished by re-using standards or existing components, such as the architecture and solution building blocks in TOGAF 9.1. Delivery time and design/development costs can also be decreased by the reuse of reference models. All that information should be managed in an Enterprise Architecture repository.

Better access to information across applications and improved interoperability

Data and information architectures manage the organization assets of information, optimally and efficiently. This supports the quality, accuracy and timely availability of data for executive and strategic business decision-making, across applications.

Readily available descriptive representations and documentation of the enterprise

Architecture is also a set of descriptive representations (i.e. “models”) that are relevant for describing an enterprise such that it can be produced to management’s requirements and maintained over the period of its useful life. Using an architecture repository, developing a variety of artifacts and modelling some of the key elements of the enterprise, will contribute to build this documentation.

The second part of the series will include more examples of what an enterprise cannot achieve without Enterprise Architecture. 

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

3 Comments

Filed under ArchiMate®, Enterprise Architecture, Enterprise Transformation, TOGAF®

When Was Your Last Enterprise Architecture Maturity Assessment

By Serge Thorn, Architecting the Enterprise

Every company should plan regular architecture capability maturity assessments using a model. These should provide a framework that represents the key components of a productive enterprise architecture process. A model provides an evolutionary way to improve the overall process that starts out in an ad hoc state, transforms into an immature process, and then finally becomes a well defined, disciplined, managed and mature process. The goal is to enhance the overall odds for success of the Enterprise Architecture by identifying weak areas and providing a defined path towards improvement. As the architecture matures, it should increase the benefits it offers the organization.

Architecture maturity assessments help to determine how companies can maximize competitive advantage, identify ways of cutting costs, improve quality of services and reduce time to market. These assessments are undertaken as part of the Enterprise Architecture management. There are some methodologies for assessment of the comprehensive Enterprise Architecture maturity. Examples of these are the U.S. Department of Commerce ACMM, the Open Group architecture maturity model and a BSC-based Architecture Score Card presented by IFEAD. For application or technology portfolios, portfolio evaluation models can be used.

As a part of project development, assessments (in reality compliance) of architecture solutions are made against the business objectives and requirements (desired process and service structures and business models) and the constraints derived from the Enterprise Architecture context (these may be standards, principles, policies or other restrictions for solution development). Assessment and compliance of technologies are also a central part of Enterprise Architecture development projects. Finally, the development of Enterprise Architectures undergoes the scrutiny of the software development quality assurance method in use. Many IT providers have adopted a comprehensive software quality assurance approach like CMMI, or ISO/IEC 15504 (known as SPICE).

Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework, to identify the gaps between the business vision and the business capabilities. Unfortunately no sufficient assessment instruments or tools have been developed for TOGAF based assessments.

Instruments or tools should contain maturity and documentation assessment questionnaires and a method on how to conduct such an assessment. In the following example you may observe four different phases on how to run an assessment:

Phase 1 would include several steps:

  • Planning & preparation workshop with the stakeholders. Stakeholders should represent both Business and IT.
  • Interviews with stakeholders based on a questionnaire related to all process areas (elements in TOGAF) or domains that have characteristics important to the development and deployment of Enterprise Architecture. Each process area could be divided into a number of practices, which are statements that describe the process area for each level of maturity, on a scale of 0 to 5. Each practice would have a set of practice indicators, evidence that the requirements for a process area to be at a given level have been met. A set of questions that will be asked in the interviews establishes whether or not the practice indicators exist and thus the level of maturity for the practice. If all the practices for a given level within a Process Area are present, then that level will be achieved. Ideally, directly relevant documentary evidence will be provided to demonstrate that the practice Indicator exists. As this is not always practical, sometimes for this exercise, only verbal evidence from subject matter experts will be considered.
  • Production of a report.
  • Calculation of a maturity score. For the representation, we use the term maturity level or organizational maturity as described below

Sources

  • CMMI for Development (Version 1.2, 2006)
  • Appraisal Requirements for CMMI (ARC) (Version 1.2, 2006)
  • The U.S. Department of Commerce Enterprise Architecture Capability Maturity Model (2007)
  • TOGAF® 9.1
  • NASCIO Enterprise Architecture Maturity Model (Version 1.3, 2003)

We then deliver a report which includes the maturity of each process area or element (There are more elements in this example than those in the chapter 51 of the TOGAF® Version 9.1).

The use of radar may also be a nice way to present the results. Please see the example below:

  • Presentation of the report to the stakeholders with strengths, weaknesses, gap analysis and recommendations
  • Next steps

Phase 2 would include several steps:

  • Based on results from Phase 1, a consensus workshop would produce a roadmap and action plan with recommendations to attain the next required level of maturity.
  • The workshop would provide a tool to produce an objective view of the report provided in Phase 1. This would give stakeholders and the senior management team a detailed view of how well Enterprise Architecture is deployed in the organization, it provides a full understanding of the business drivers and organization issues and a clear view of where the stakeholders want the organization to be. The outputs of this phase are priorities, and an action plan that is agreed and understood by the key stakeholders in the organization. There could also be a target radar diagram as shown below:

The updated report may then look like this:

Phase 3 would be the management of Enterprise Architecture as described in the report and Phase 4, which is similar to Phase 1.

Conducting an evaluation of an organization’s current practices against an architecture capability maturity assessment model allows companies to determine the level at which it currently stands. It will indicate the organization’s maturity in the area of Enterprise Architecture and highlight the practices that the organization needs to focus on in order to see the greatest improvement and the highest return on investment. The recommendation is that assessments should be carried out annually.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

1 Comment

Filed under Enterprise Architecture, TOGAF®

5 Tips Enterprise Architects Can Learn from the Winchester Mystery House

By E.G.Nadhan, HP Enterprise Services

Not far from where The Open Group Conference was held in San Francisco this week is the Winchester Mystery House, once the personal residence of Sarah Winchester, widow of the gun magnate William Wirt Winchester. It took 38 years to build this house. Extensions and modifications were primarily based on a localized requirement du jour. Today, the house has several functional abnormalities that have no practical explanation.

To build a house right, you need a blueprint that details what is to be built, where, why and how based on the home owner’s requirements (including cost). As the story goes, Sarah Winchester’s priorities were different. However, if we don’t follow this systematic approach as enterprise architects, we are likely to land up with some Winchester IT houses as well.

Or, have we already? Enterprises are always tempted to address the immediate problem at hand with surprisingly short timelines. Frequent implementations of sporadic, tactical additions evolve to a Winchester Architecture. Right or wrong, Sarah Winchester did this by choice. If enterprises of today land up with such architectures, it can only by chance and not by choice.

So, here are my tips to architect by choice rather than chance:

  • Establish your principles: Fundamental architectural principles must be in place that serve as a rock solid foundation upon which architectures are based. These principles are based on generic, common-sense tenets that are refined to apply specifically to your enterprise.
  • Install solid governance: The appropriate level of architectural governance must be in place with the participation from the stakeholders concerned. This governance must be exercised, keeping these architectural principles in context.
  • Ensure business alignment: After establishing the architectural vision, Enterprise Architecture must lead in with a clear definition of the over-arching business architecture which defines the manner in which the other architectural layers are realized. Aligning business to IT is one of the primary responsibilities of an enterprise architect.
  • Plan for continuous evaluation: Enterprise Architecture is never really done. There are constant triggers (internal and external) for implementing improvements and extensions. Consumer behavior, market trends and technological evolution can trigger aftershocks within the foundational concepts that the architecture is based upon.

Thus, it is interesting that The Open Group conference was miles away from the Winchester House. By choice, I would expect enterprise architects to go to The Open Group Conference. By chance, if you do happen by the Winchester House and are able to relate it to your Enterprise Architecture, please follow the tips above to architect by choice, and not by chance.

If you have instances where you have seen the Winchester pattern, do let me know by commenting here or following me on Twitter @NadhanAtHP.

This blog post was originally posted on HP’s Transforming IT Blog.

HP Distinguished Technologist, E.G.Nadhan has over 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project and is also the founding co-chair for the Open Group Cloud Computing Governance project. Twitter handle @NadhanAtHP.

4 Comments

Filed under Enterprise Architecture, TOGAF®

What’s New in ArchiMate 2.0?

By Andrew Josey, The Open Group, Henry Franken, BiZZdesign

ArchiMate® 2.0, an Open Group Standard, is an upwards-compatible evolution from ArchiMate 1.0 adding new features, as well as addressing usage feedback and comments raised.

ArchiMate 2.0 standard supports modeling throughout the TOGAF Architecture Development Method (ADM).

Figure 1: Correspondence between ArchiMate and the TOGAF ADM

ArchiMate 2.0 consists of:

  • The ArchiMate Core, which contains several minor improvements on the 1.0 version.
  • The Motivation extension, to model stakeholders, drivers for change, business goals, principles, and requirements. This extension mainly addresses the needs in the early TOGAF phases and the requirements management process.
  • The Implementation and Migration extension, to support project portfolio management, gap analysis, and transition and migration planning. This extension mainly addresses the needs in the later phases of the TOGAF ADM cycle.

ArchiMate 2.0 offers a modeling language to create fully integrated models of the organization’s enterprise architecture, the motivation for the enterprise architecture, and the programs, projects and migration paths to implement this enterprise architecture. In this way, full (forward and backward) traceability between the elements in the enterprise architecture, their motivations and their implementation can be obtained.

In the ArchiMate Core, a large number of minor improvements have been made compared to ArchiMate 1.0: inconsistencies have been removed, examples have been improved and additional text has been inserted to clarify certain aspects. Two new concepts have been added based on needs experienced by practitioners:

  • Location: To model a conceptual point or extent in space that can be assigned to structural elements and, indirectly, of behavior elements.
  • Infrastructure Function: To model the internal behavior of a node in the technology layer. This makes the technology layer more consistent with the other two layers.

The Motivation extension defines the following concepts:

  • Stakeholder: The role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.
  • Driver: Something that creates, motivates, and fuels the change in an organization.
  • Assessment: The outcome of some analysis of some driver.
  • Goal: An end state that a stakeholder intends to achieve.
  • Requirement: A statement of need that must be realized by a system.
  • Constraint: A restriction on the way in which a system is realized.
  • Principle: A normative property of all systems in a given context or the way in which they are realized.

For motivation elements, a limited set of relationships has been defined, partly re-used from the ArchiMate Core: aggregation (decomposition), realization, and (positive or negative) influence.

The Implementation and Migration extension defines the following concepts (and re-uses the relationships of the Core):

  • Work Package: A series of actions designed to accomplish a unique goal within a specified time.
  • Deliverable: A precisely defined outcome of a work package.
  • Plateau: A relatively stable state of the architecture that exists during a limited period of time.
  • Gap: An outcome of a gap analysis between two plateaus.

ArchiMate 2 Certification

New with ArchiMate 2.0 is the introduction of a certification program. This includes certification for people and accreditation for training courses. It also includes certification for tools supporting the ArchiMate standard.

The ArchiMate 2 Certification for People program enables professionals around the globe to demonstrate their knowledge of the ArchiMate standard. ArchiMate 2 Certification for People is achieved through an examination and practical exercises as part of an Accredited ArchiMate 2 Training Course.

The Open Group Accreditation for ArchiMate training courses provides an authoritative and independent assurance of the quality and relevance of the training courses.

The Open Group ArchiMate Tool Certification Program makes certification available to tools supporting ArchiMate. The goal of the program is to ensure that architecture artifacts created with a certified tool are conformant to the language.

Further Reading

ArchiMate 2.0 is available for online reading and download from The Open Group Bookstore at www.opengroup.org/bookstore/catalog/c118.htm.

A white paper with further details on ArchiMate 2.0 is available to download from The Open Group Bookstore at www.opengroup.org/bookstore/catalog/w121.htm .

Andrew Josey is Director of Standards within The Open Group. He is currently managing the standards process for The Open Group, and has recently led the standards development projects for TOGAF 9.1, ArchiMate 2.0, IEEE Std 1003.1-2008 (POSIX), and the core specifications of the Single UNIX Specification, Version 4. Previously, he has led the development and operation of many of The Open Group certification development projects, including industry-wide certification programs for the UNIX system, the Linux Standard Base, TOGAF, and IEEE POSIX. He is a member of the IEEE, USENIX, UKUUG, and the Association of Enterprise Architects.

Henry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

Comments Off

Filed under ArchiMate®, Business Architecture, Enterprise Architecture, Standards, TOGAF, TOGAF®