Category Archives: 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®

How to manage requirements within the Enterprise Architecture using the TOGAF® and SABSA® frameworks

By Pascal de Koning, KPN 

You want to put your company’s business strategy into action. What’s the best way to accomplish this?  This can be done in a structured manner by using an Enterprise Architecture
Framework like TOGAF®. TOGAF® offers an overview of business and IT related architectures, as well as a process model to deliver these, called the Architecture Development Method (ADM-figure 1).

As the figure shows, Requirements Management plays a central role in the architecture work in the TOGAF® methodology. It’s very important to know the business requirements, because these demand what’s needed in the underlying architecture layer. In fact, this counts for every layer. Each architecture layer fulfills the requirements that are defined in the layer above. Without proper Requirements Management, the whole architecture would be loose sand.

Unfortunately, TOGAF® does not offer guidance on Requirements Management. It does however stress the importance and central role of Requirements Management, but doesn’t offer a way to actually do Requirements Management. This is a white spot in the TOGAF® ADM. To resolve this, a requirements management method is needed that is well-described and flexible to use on all levels in the architecture. We found this in the SABSA® (Sherwood’s Applied Business-driven Security Architecture) framework. SABSA® offers the unique Business Attribute Profiling (BAP) technique as a means to effectively carry out Requirements Management.

Business Attribute Profiling is a requirements engineering technique that translates business goals and drivers into requirements (see figure 2). Some advantages of this technique are:

  • Executive communication in non-ICT terms
  • Grouping and structuring of requirements, keeping oversight
  • Traceability mapping between business drivers, requirements and capabilities

The BAP process decomposes the business goal into its core elements. Each core element is a single business attribute. Examples of business attributes are Available, Scalable, Supported, Confidential, Traceable, etc.

As business processes tend to become more Internet-based, cyber security is becoming more important every day because the business processes are increasingly vulnerable to forces outside the business. Organizations must now consider not only the processes and requirements when planning an architecture, but they also need to consider the security of that architecture. A Security Architecture consists of all the security-related drivers, requirements, services and capabilities within the Enterprise. With the adoption of the Business Attribute Profiling technique for Requirements Management, it is now possible to integrate information security into the Enterprise Architecture.

The TOGAF®-SABSA® Integration white paper elaborates more on this and provides a guide that describes how TOGAF® and SABSA® can be combined such that the SABSA® business risk-driven security architecture approach is seamlessly integrated into the a TOGAF®-based enterprise architecture. It can be downloaded from https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

TOGAF® is a registered trademark of The Open Group.  SABSA® is a registered trademark of The SABSA Institute.

Pascal de Koning MSc CISSP is a Senior Business Consultant with KPN Trusted Services, where he leads the security consulting practice. He is chairman of The Open Group TOGAF-SABSA Integration Working Group. He has worked on information security projects for the Dutch central government, European Union and KPN, to name just a few. Pascal has written articles for Computable and PvIB, and is a frequent speaker at conferences like RSA Europe and COSAC on the topics of Cyber Security and Enterprise Security Architecture. When not working, Pascal loves to go running.

1 Comment

Filed under Enterprise Architecture, Security Architecture, TOGAF®

Why do pencils have erasers?

By Andrew Josey and Garry Doherty, The Open Group

We know that TOGAF® isn’t perfect. In fact, it probably never will be, but sometimes, especially after a major release, it’s a good idea to stop and look backwards after its been in implementation for a while… just to make sure we’ve gotten it right and to review the standard for reasons of further clarification and to improve consistency.

That’s why we’re releasing TOGAF® 9.1. It contains a set of corrections to address comments raised since the introduction of TOGAF® 9 in 2009. We have been able to address over 400 of the comments received against TOGAF® 9, resulting in over 450 changes to the standard.

The maintenance updates in TOGAF® 9.1 are based on feedback received on the framework as organizations have put it to good use over the past three years. As such the changes are upwards compatible adding clarification, consistency and additional detail where needed. Some of the most significant updates include:

  • The SOA chapter (Part III, Chapter 22, Using TOGAF to Define & Govern SOAs) has been updated to include the latest Open Group SOA Work Group output providing guidance on adapting the ADM phases for SOA
  • ADM Phases E and F (Part II, Chapters 13 and 14) have been reworked to match the level of detail in other phases, and the uses of terminology for Transition Architecture, Roadmap, and Implementation Strategy clarified and made consistent
  • Corrections have been applied to aspects of the Content Metamodel (Part IV, Chapter 34, The Content Metamodel) including the metamodel diagrams
  • The concepts of levels, iterations and partitions have been clarified and made consistent. This includes a reorganization of material in Part III, Chapter 19, Applying Iteration to the ADM and Chapter 20, Applying the ADM across the Architecture Landscape, and also Part V, Chapter 40, Architecture Partitioning
  • The terms “artifact” versus “viewpoint” have been clarified and made consistent. This includes a restructuring of Part IV, Chapter 35, Architectural Artifacts
  • Changes have been made to improve general usability including:
    • The artifacts for each phase are now listed in the phase descriptions
    • Duplicate text in several places has been replaced with an appropriate reference
    • The “Objectives” sections of the phases have been reworked
    • Some artifacts have been renamed to better reflect their usage

If you’re already TOGAF® 9 certified,  don’t worry about the status of your certification. The TOGAF® 9 Certification for People Program has been designed to accommodate maintenance updates to the TOGAF® 9 standard such as TOGAF® 9.1. So impacts on the program are minimal:

  • The two levels of certification remain as TOGAF® 9 Foundation and TOGAF® 9 Certified.
  • Individuals who are currently certified in the TOGAF® 9 People Certification program remain certified.

TOGAF 9.1 is available for online reading at http://www.opengroup.org/togaf/ and available in The Open Group Bookstore at http://www.opengroup.org/bookstore/catalog/g116.htm .

A detailed description of the changes between TOGAF 9 and TOGAF 9.1 is available at http://www.opengroup.org/bookstore/catalog/u112.htm .

So now you know why pencils have erasers… because perfection is a constantly moving target!

5 Comments

Filed under Enterprise Architecture, Standards, TOGAF, TOGAF®

What does developing an IT Strategy mean?

By Serge Thorn, Architecting the Enterprise

I have observed many situations where a c-level person was supposed to document an IT Strategy in a short period of time, in order to prepare the following year’s annual budget. Very often, they lack much supporting documented business information in order to achieve this task. The result is a weak strategy, sometimes ignored by the user’s community, the key stakeholders.

A weak IT strategy can be costly and wasteful, especially for resource-constrained organizations that operate with minimal budget, tools, knowledge and people.  It also implies that organizations cannot respond to changing business requirements rapidly enough. The absence of strategic anticipation causes organizations to be inefficiently reactive, forcing them to work in a constant state of catch-up.

An IT Strategy should answer the following questions:

  • Are we doing the right things with technology to address the organization’s most important business priorities and continuously deliver value to the clients?
  • Are we making the right technology investments?
  • Do we measure what is the real value to the organization derived from that technology?
  • Is our current Information Technology agile enough; flexible to continuously support a successful organization?
  • Is our Information Technology environment properly managed, maintained, secured, able to support the clients, and is it cost effective?
  • Can our strategy support current and future business needs?

Quite often the first thing we should consider when writing such a document is the targeted audience and its content. Different people with varying roles and responsibilites may read an IT Strategy within a company, so the document may need to serve several different purposes.  It is not easy to pitch a strategy to different levels in the hierarchy within an organization, and at the appropriate level of detail. Sometimes it is too detailed and does not always match the stakeholder’s needs.

An IT Strategy is an iterative process to align IT capabilities with the business strategy and requirements:

  • It is a documented and approved process (part of the organization’s governance framework)
  • It is iterative (it needs to be frequently be revisited). Traditionally, IT strategies are updated and communicated on an annual basis, usually to meet budget cycles. This should be considered the minimum review period. If an emerging technology surfaces that has the potential to enhance the business, it should be investigated and communicated to the business as soon as possible. A one-year cycle may  be too late.
  • It  is a strong alignment of business and IT capabilities rather than designing IT solutions to support business requirements
    • Assuming  that both business and IT capabilities drive each other
    • Assuming that business drives IT and not the other way around
  • The IT Strategy sets future direction for IT function in the organization
    • Ensuring that the IT budget is spent on value creation activities for the business
    • Creating shareholder value
    • Helping to maximize the return on IT investments
  • The IT Strategy may include sub-elements such as:
    • Infrastructure strategy
    • Application strategy
    • Integration strategy
    • Service strategy
    • Sourcing strategy
    • Innovation strategy

This pyramid diagram can be used to illustrate the IT strategy and vision, and how the technology and business strategies are totally aligned. At the top of the pyramid is the enterprise overarching vision. Aligned below that is how IT supports the vision by becoming a premier IT organization in creating competitive advantage for the clients. The IT vision is in turn supported by three pillars: integration, improvement, and innovation.

To deliver this, the business strategy should clearly be articulated and documented taking into account some IT aspects. There are different ways of gathering these business inputs.

The first approach is a very classical one where you develop a questionnaire in business terms which asks each business unit to identify their future requirements for infrastructure growth, taking into account capacity and availability requirements. This extracts the data you need for business driven strategy.

This questionnaire may include some of the following examples of questions:

  1. What are your top 5 business “pain” points? These are things that you wish you had a solution for
  2. What are your top 5 business objectives? These can be short term or long term, can be driven by revenue, cost, time, time to market, competitive advantage, risk or various other reasons
  3. How do you plan to achieve these objectives?
  4. What will we gain by leveraging IT Capabilities across the business?
  5. What is in the way of achieving your business imperatives?
  6. Can IT help achieve your business imperatives?
  7. How much do you spend on IT capabilities?
  8. What is your technology ROI?
  9. Does your company have a plan for technology?
  10. Does your business plan include a technology plan?
  11. Where is IT being used across your business unit?

The second approach would be the use of Enterprise Architecture that I will explain later on.

With this input you may now start to consider the structure of your document. It may look similar to this example below:

An executive summary

  • An introduction
    • The purpose
    • The background
    • The Business drivers
    • The Organizational drivers
    • The IT drivers
  • The Business and IT aspects
    • The Business Goals and Objectives
    • The IT approaches and principles
  • The IT components
    • Business application systems
    • IT infrastructure
    • Security and IT Service continuity
  • Structure, organization and management
    • IT Governance
    • Skills, knowledge and education
    • IT Financial management
    • KPIS, measurement and metrics, balance scorecards
  • Technologies opportunities
  • Key issues

And this is where Enterprise Architecture may have to play an important and even crucial role. Some companies I have encountered have an Enterprise Architecture team, and in parallel, somebody called an IT Strategist. Frequently the connection is non-existing or quite weak.  Other organizations may also have a Strategic Planning unit, again without any connection with the Enterprise Architecture team.

An Enterprise Architecture must play the important role of assessing; existing IT assets, architecture standards and the desired business strategy to create a unified enterprise-wide environment – where the core hardware and software systems are standardised and integrated across the entire organisation’s business processes, to greatly enhance competitive advantage and innovation. The IT Strategy details the technologies, application and the data foundation needed to deliver the goals of the corporate strategy, while Enterprise Architecture is the bridge between strategy and execution; providing the organising logic to ensure the integration and standardisation of key processes that drive greater agility, higher profitability, faster time to market, lower IT costs, improved access to shared customer data and lower risk of mission-critical systems failures.

As a real example, TOGAF 9 is perfect way to produce that IT Strategy document during the Phase F: Migration Planning.

Below you will find the relationship between some phases of the ADM and the structure of the above document. It needs to be said that we should probably use a Strategic architecture level to deliver a first version of the document, which then could be reviewed with Segment or Capability architectures.

Content Examples Enterprise Architecture and TOGAF
An executive summary
An introduction (This document must be business oriented)
Content Examples Enterprise Architecture and TOGAF
The purpose Key elements of the scope, audience, time horizon The Preliminary phase is about defining ‘‘where, what, why, who, and how” Enterprise Architecture will be done and will provide all information. It also creates the conditions and context for an Architecture Capability
The background Business problems, constraints (financial, resources, IT, legal, etc.) This is covered by the Phase A: Architecture Vision. An Architecture Visionsets stage for each iteration of ADM cycle.-Provides high-level, aspirational view of target the sponsor uses to describe how business goals are met and stakeholder concerns are addressed
-Provides an executive summary version of full Architecture
-Drives consensus on desired outcomeThe Business Scenarios is used to discover and document business requirements, identify constraints, etc.
The Business drivers Market conditions, competition, consumer trends, new customers, products sales, costs savings, incremental services revenues, drivers related to the IT function In the Phase A: Architecture Vision, we:Identify business goals and strategic drivers-Ensure that descriptions used are current-Clarify any areas of ambiguityDefine constraints-Enterprise-wide constraints

-Architecture project-specific constraints

The Organizational drivers Profitability, financial performance, change in strategic objectives, end of the product development life cycle, mergers and acquisitions, staffs, risks
The IT drivers New or obsolete technologies, updates Considering that IT is part of the Business, these drivers should also be considered in that phase
The Business and IT aspects
The Business Goals and Objectives Market growth, entering new markets, addressing manufacturing capacities In the Phase A: Architecture Vision, we:Identify business goals and strategic drivers
-Ensure that descriptions used are current
-Clarify any areas of ambiguity
-Define constraints
-Enterprise-wide constraints
-Architecture project-specific constraints
The IT approaches and principles IT standards, development, implementation, delivery, testing, consolidation, maturity, best practices Standards should be documented in the SIB (Standard Information Base)When we define the Architecture Governance Framework during the Preliminary Phase, we identy the various touch points with existing other frameworks in the organization
IT principles should have already have been defined by the IT department
The IT components
Business application systems Baseline (main applications: ERP, CRM, customers facing systems). Future plans, concerns, time period, priorities) This will be addressed by Phase C: Information Systems based on the Statement of Architecture Work, output from the Phase A
IT infrastructure Baseline (servers, network , middleware, technical services) This will be addressed by Phase D: Technology Architecture based on the Statement of Architecture Work, output from the Phase A
Security and IT Service continuity Issues, challenges, opportunities related to security, security principles, controls Security concerns are addressed during all phases of the ADM
Structure, organization and management
IT Governance Best practices, frameworks, management and monitoring, resource management, portfolio management, vendors management, IT service management, project management, etc. IT Governance will be considered when the Architecture Governance Framework is defined. There will obviously be touch points between the ADM and some other best practices used by the organization. IT Governance is defined outside of the Enterprise Architecture programme
Skills, knowledge and education Skills, knowledge and education Enterprise Architecture skills will have to be addressed by the Architecture Capability Framework. Other skills may also be identified independently of the Enterprise Architecture programme
IT Financial management IT budget, costs structures, measurement and metrics, targets, areas needing investments, etc. This is addressed is outside of the Enterprise Architecture programme
KPIS, measurement and metrics, balance scorecards IT performance measurements on SMART objectives ((Specific, Measurable, Achievable, Realistic, & Time bound) Every governance frameworks may have its own KPIs. Enterprise Architecture KPIs may be added to that list.
Technologies opportunities Emerging technologies, business related benefits This can be done in parallel of the Enterprise Architecture programme
Key issues and initiatives Summary or link to the IT Project portfolio This can be done in parallel of the Enterprise Architecture programme
Color legend
Direct relationship with Enterprise Architecture
Indirect relationship with Enterprise Architecture
Produced somewhere else

The next step would be the review of the IT Strategy document by the main stakeholders who would accept or reject technology opportunities. This could also be used as an important source of information for the Strategic Planning exercise (please refer to another article for additional information:  “How Strategic Planning relates to Enterprise Architecture?“).

Once the IT Strategy has been reviewed, amended and authorised (which should in reality already be approved, as it is the result of various ADM cycles and the output of Phase F: Migration planning), the multi-disciplinary programme team for the implementation during Phase G: Implementation Governance, will deliver the solutions to the business.

As already mentioned previously, the outline strategies will be refined and expanded with a low level of detail when addressing Segment and Capability architectures. This is the part that meets the first challenge described above, where we need different levels of detail for different stakeholders. The documents should be hierarchical, with the ability to drill down to lower levels as more detail is required.

One of the main reasons for developing an Enterprise Architecture with TOGAF 9 is to support the business by providing the fundamental technology and process structure for an IT Strategy.  Enterprise Architecture is the superset that represents both Business and IT Strategy; this is reflected in Enterprise Architecture’s basic structure of strategy, business architecture and technology/information architecture. One can certainly do an IT Strategy without Enterprise Architecture, but Enterprise Architecture cannot be done without an IT Strategy; the same would apply to business strategy/business 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 has more than 20 years of experience in Banking and Finance and 5 years of experience in the Pharmaceuticals industry. Among various roles, he has been responsible for the Architecture team in an international bank, where he gained wide experience in the deployment and management of information systems in Private Banking, Wealth Management, and also in IT architecture domains such as the Internet, dealing rooms, inter-banking networks, and Middle and Back-office. He then took charge of IT Research and Innovation (a function which consisted of motivating, encouraging creativity, and innovation in the IT Units), with a mission to help to deploy a TOGAF based Enterprise Architecture, taking into account the company IT Governance Framework. He also chaired the Enterprise Architecture Governance worldwide program, integrating the IT Innovation initiative in order to identify new business capabilities that were creating and sustaining competitive advantage for his organization. Serge has been a regular speaker at various conferences, including those by The Open Group. His topics have included, “IT Service Management and Enterprise Architecture”, “IT Governance”, “SOA and Service Management”, and “Innovation”. Serge has also written several articles and whitepapers for different magazines (Pharma Asia, Open Source Magazine). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

3 Comments

Filed under Enterprise Architecture, Semantic Interoperability, TOGAF®

The Open Group and SABSA Institute Publish TOGAF® Integration Whitepaper

By Jim Hietala, Vice President, Security, The Open Group

2011 confirmed what many in the Enterprise Architecture industry have feared – data breaches are on the rise. It’s not just the number and cost of data breaches, but the sheer volume of information that cyber criminals are able to get their hands on. Today’s organizations cannot risk being vulnerable.

To help address this issue, The Open Group Security and Architecture Forums, and the SABSA® Institute, developers of the SABSA® security and risk management framework, joined forces to explore how security methodologies and risk management approaches can be an integrated with enterprise-level architectures for better protection and flexibility.

If you are an enterprise architect with responsibility for ensuring architectures are secure or a security professional tasked with developing secure architectures you’ll be interested in the work the Architecture Forum and SABSA® have done over the last 15 months, culminating in a whitepaper released today that provides a valuable contribution to the security and enterprise architecture communities.

 A Project Designed to Protect

All too often vulnerabilities can occur due to lack of alignment across organizations, with security and IT experts failing to consider the entire infrastructure together rather than different parts separately.

The impetus for this project came from large enterprises and consulting organizations that frequently saw TOGAF® being used as a tool for developing enterprise architecture, and SABSA® as a tool for creating security architectures. Practitioners of either TOGAF® or SABSA® asked for guidance on how best to align these frameworks in practical usage, and on how to re-use artifacts from each.

This quote from the whitepaper sums up the rationale for the effort best:

 “For too long, information security has been considered a separate discipline, isolated from the enterprise architecture. This Whitepaper documents an approach to enhance the TOGAF® enterprise architecture methodology with the SABSA® security architecture approach and thus create one holistic architecture methodology.”

The vision for the project has been to support enterprise architects who need to take operational risk management into account, by providing guidance describing how TOGAF® and SABSA® can be combined such that the SABSA® business risk and opportunity-driven security architecture approach can be seamlessly integrated into the TOGAF® business strategy-driven approach to develop a richer, more complete enterprise architecture.

There are two important focal points for this effort, first to provide a practical approach for seamlessly integrating SABSA® security requirements and services in common TOGAF®-based architecture engagements – instead of treating security as a separate entity within the architecture.

The second focal point is to illustrate how the requirements management processes in TOGAF® can be fulfilled in their widest generic sense (i.e., not only with regard to security architecture) by application of the SABSA® concept of Business Attribute Profiling to the entire ADM process.

Download a free copy of the TOGAF® and SABSA® whitepaper here.

If you are interested in exploring TOGAF® 9, online access to the framework is available here.

Information on SABSA® may be obtained here.

A large number of individuals participated in the development of this valuable resource. Thank you to all project team members who made this effort a reality, including from the SABSA® Institute, the Open Group Architecture Forum, and the Open Group Security Forum!

3 Comments

Filed under Enterprise Architecture, Security Architecture, TOGAF®

What is Business Technology Management and how does it relate to Enterprise Architecture?

By Serge Thorn, Architecting the Enterprise

Business Technology Management (BTM) is not a methodology but I would say a concept, or eventually the aggregation of several guidelines and techniques. It is also described as a management science which aims to unify business and technology business strategies with the aim of extracting the full potential value of business technology solutions. In a nutshell, it allows you to unify business and technology decision making. Sound familiar?

Continue reading

2 Comments

Filed under Enterprise Architecture, TOGAF®

How EA is leading enterprise transformation in France

By Eric Boulay, The Open Group France

Earlier this week, in Paris, The Open Group France held the latest in a series of one-day conferences focused on Enterprise Architecture. As usual, the event delivered high-value content in the form of an excellent keynote presentation and case studies. These covered the retail, gambling, and financial industries — including two from CIOs of major French corporations: Continue reading

2 Comments

Filed under Enterprise Architecture, TOGAF®

Are Business Process Management and Business Architecture a perfect match?

by Serge Thorn, Architecting the Enterprise

Whenever I suggest collaboration between these two worlds, I always observe some sort of astonishment from my interlocutors. Many Enterprise Architects or Business Architects do not realise there may be synergies. Business Process Management (BPM) team have not understood what Enterprise Architecture is all about and the other way around… There is no a single definition of Business Process Management, often it means different things to different people. To keep it very generic, BPM relates to any activities an organization does to support its process efforts.

There are many activities which can be included in such efforts:

  • The use of industry Business Reference Model (or Business Process Reference Model), a reference for the operational activities of an organization, a framework facilitating a functional Lines of Business, such as
      • The Federal Enterprise Architecture Business Reference Model of the US Federal Government
      • The DoD Business Reference Model
      • The Open Group Exploration and Mining Business Reference Model
      • Frameworx (eTOM) for Telco companies
      • The Supply Chain Operations Reference (SCOR®) model
      • The SAP R/3 Reference Model
      • The Oracle Business Models : Oracle Industry Reference Model for Banking, (IRM), Oracle Retail Reference Model
      • And others…
  • The use of organization specific Business Reference models
  • The use of Business process improvement methodologies
      • Lean, a quantitative data driven methodology based on statistics, process understanding and process control
      • Six Sigma, a methodology that mainly focuses on eliminating bad products or services to clients by using statistical evaluation
  • Business Process Reengineering, which in reality is a facet of BPM
  • The understanding of Business Change Management, the process that empowers staff to accept changes that will improve performance and productivity
  • The understanding of Business Transformation, the continuous process, essential to any organization in implementing its business strategy and achieving its vision
  • The use of Business Rules Management which enables organizations to manage business rules for decision automation
  • The understanding of Business Process Outsourcing (BPO) services to reduce costs and increase efficiency
  • The support of Business Process modeling and design, which is illustrated description of business processes, usually created with flow diagrams. The model contains the relationship between activities, processes, sub-processes and information, as well as roles, the organization and resources. This can done with many notations such as flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, IDEF, and nowadays with the standard de facto notations such as UML and BPMN
  • The support of BPM tools and suites implementation. With the right, process models can be simulated, to drive workflow or BPMS systems, and can be used as the basis for an automated process monitoring system (BAM)
  • The support of Business Activity Monitoring (BAM), the ability to have end-to-end visibility and control over all parts of a process or transaction that spans multiple applications and people in one or even more companies

To combine Business Process Management and Enterprise Architecture for better business outcomes is definitely the way forward, where BPM provides the business context, understanding, and- metrics, and Enterprise Architecture provides the discipline to translate business vision and strategy into architectural changes. Both are needed for sustainable continuous improvement. When referring to Enterprise Architecture, we would mainly refer to Business Architecture. Business Architecture involves more than just the structure of business processes. It also entails the organization of departments, roles, documents, assets, and all other process-related information.

Business Architects may be defining and implementing the Business Process framework and, in parallel, influencing the strategic direction for Business Process Management and improvement methodologies (e.g. Lean, Six Sigma). The business process owners and Business Analysts are working within their guidelines at multiple levels throughout the organizations’ business process. They have roles and responsibilities to manage, monitor and control their processes.

An important tool in developing Business Architecture is a Business Reference Model. These types of models are enormously beneficial. They can be developed in the organization to build and extend the information architecture. The shared vocabulary (verbal and visual) that emerges from these efforts promotes clear and effective communication.

To illustrate the touch points between Enterprise Architecture and Business Process Management, I have illustrated in the table below the synergies between the two approaches using TOGAF® 9.

In this table, we observe that, there is a perfect match between Business Process Management and the use of an Enterprise Architecture framework such as TOGAF. BPM is often project based and the Business Architect (or Enterprise Architect) may be responsible for identifying cross-project and cross-process capabilities. It can be considered as being the backbone of an Enterprise Architecture program. We can also add to this, that Service Oriented Architecture is the core operational or transactional capability while BPM does the coordination and integration into business processes.

When using BPM tools and suites, you should also consider the following functionalities: workflow, enterprise application integration, content management and business activity monitoring. These four components are traditionally provided by vendors as separate applications which are merged through BPM into a single application with high levels of integration. The implementation of a BPM solution should theoretically eliminate the maintenance and support cost of these four applications resulting in reducing the total cost of ownership.

Business Architecture provides the governance, alignment and transformational context for BPM across business units and silos. Enterprise Architects, Business Architects, Business Analysts should work together with BPM teams, when approaching the topic of Business Process Management. BPM efforts need structures and appropriate methodologies. It needs a structure to guide efforts at different levels of abstraction (separating “the what“ (the hierarchical structure of business functions) from “the how” (how the desired results are achieved), a documented approach and structure to navigate among the business processes of the organization, i.e. a Business Architecture. They also need a methodology such as an Enterprise Architecture framework to retain and leverage what they have learned about managing and conducting BPM projects.

Editor’s note: The Open Group Architecture Forum and the TM Forum have published a technical report exploring the synergies and identifying integration points between TOGAF and Frameworx. Download it here

This article has previously appeared in Serge Thorn’s personal blog and appears here with his permission.

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 has more than 20 years of experience in Banking and Finance and 5 years of experience in the Pharmaceuticals industry. Among various roles, he has been responsible for the Architecture team in an international bank, where he gained wide experience in the deployment and management of information systems in Private Banking, Wealth Management, and also in IT architecture domains such as the Internet, dealing rooms, inter-banking networks, and Middle and Back-office. He then took charge of IT Research and Innovation (a function which consisted of motivating, encouraging creativity, and innovation in the IT Units), with a mission to help to deploy a TOGAF based Enterprise Architecture, taking into account the company IT Governance Framework. He also chaired the Enterprise Architecture Governance worldwide program, integrating the IT Innovation initiative in order to identify new business capabilities that were creating and sustaining competitive advantage for his organization. Serge has been a regular speaker at various conferences, including those by The Open Group. His topics have included, “IT Service Management and Enterprise Architecture”, “IT Governance”, “SOA and Service Management”, and “Innovation”. Serge has also written several articles and whitepapers for different magazines (Pharma Asia, Open Source Magazine). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

3 Comments

Filed under Enterprise Architecture, TOGAF®