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

Monet revisited (or: non-traditional approaches to developing TOGAF® Next)

By Stuart Boardman, Getronics

Right now work is starting on the next major release of TOGAF®, which for now is known as TOGAF® Next. That makes it a very good time to look at what else is going on in the world and what kind of contribution that might make.

A lot of the best ideas come from unexpected directions. Enterprise architects (fortunately) often have passions that don’t have much directly to do with that discipline. Let’s be honest, the best ones almost always do. Peter Bakker recently drew our attention to a current debate in the world of photography and photo journalism. People are using apps like Hipstamatic to make deliberately grungy images – to make the results less “realistic” and more “impressionistic” (same thing Claude Monet and his pals came up with in the late 19th century except they didn’t have apps back then). Apart from the intrinsic interest of the topic, Peter suggested this might be applicable in EA. That made me think. We’ve invested vast amounts of time and effort (and therefore money) in being able to specify things in enormous detail according to increasingly tightly defined models. In fact, people used to complain that those tight models were what TOGAF® lacked. Hmmm. Sometimes the result is not seeing the wood for the trees. Or assuming that detail equals fact. Or getting realism muddled up with reality. Or information with knowledge (never mind wisdom). The Impressionists wanted people to be able to get a feeling of what it was like to be there — not precisely what it looked like at a specific moment in time. So while I’m sure they weren’t thinking about quantum mechanics (that would have been quite an achievement!), they were certainly leaving things open for probabilistic interpretations. Could we do the same in EA – without just producing vagueness? Why not – at least down to a certain level? If you use the Business Model Canvas, for example, you can build up a very meaningful picture of an enterprise’s business model without vast amounts of detail. It provides a lot of knowledge and even some wisdom on the basis of an optimal amount of information. And that has the great benefit of allowing you to fill in the detail where it’s actually going to be useful to you. So why wouldn’t we do something similar in general in EA?

Ross Button is developing an idea he calls Scatter Architecture. You could visualize it as a lot of puzzle pieces that you scatter on a board and see what kind of a picture you can make out of them. They might turn out to fit together in more than one way. That’s actually a good thing, as it probably makes you more adaptable and less exposed to change. Some of the pieces will duplicate each other wholly or partly. Viewed from a TOGAF® perspective we can say that these duplicates occur both on the Enterprise Continuum and on the Solution Continuum. Duplicates are allowed in this architecture. I don’t suppose you’d find them in the Enterprise Strategy or in the Architecture Strategy but you might well find partial duplicates among your propositions, activities, resources and partners – particularly the latter. After all, you probably don’t really want to be dependent on one supplier but that doesn’t mean they’re all exactly alike. So your architecture strategy might even codify that, which means your architecture models will need to take account of it. On the solution side of things it’s just as likely. Ross has explicitly pointed to Cloud as an example of this. Just as in the “real” world, if you can avoid being locked into just one supplier (without the cost implications being too high), you have much more room to manoeuver. The Amazon crash a couple of months ago provided some good positive and negative examples. Moreover, just as in the “real” world, these partners might become part of your value creation process as opposed to just cost elements. So this introduces my second theme, multiplicity.

Louisa Leontiades has just launched a social media integrated business. It’s a great example of how enterprises are changing and why we need to understand them in non-traditional ways. What can we say about her business? Well, it’s an Internet company but it’s not selling technology. It sells real people skills but everything lives in the blogosphere. You can buy her stuff via the site but it’s not an eShop. It’s Louisa’s company but in some ways it’s a virtual enterprise. What does that mean? Well, there will be multiple contributors generating and selling content and the quality and commercial success of the content will shape how the company develops. Or to put it another way, the contributors are not merely suppliers but actually investors, who benefit from the success of the company. Oh and it has its own website but the marketing happens via separate blog sites, via Twitter, Facebook, Google+, LinkedIn – you name it. It’s easy to see then how capturing the architecture of such an enterprise is about capturing the essence and not getting distracted by detail that can change at any moment – exactly due to the multiplicity of contributors and propositions. It’s a daring concept – jumping into the unknown – and of course we won’t see this model in the large enterprise world for quite some time but in the non-profit world or perhaps even in education one could imagine a more rapid adoption. In fact you might reasonably expect to see it adopted in education. It was after all educational and research organizations that gave us the Web in the first place. And back then the web was all about collaboration and sharing – co-creation.

Tom Graves has been looking at extending the Business Model Canvas into Enterprise Architecture as a whole. One part of this is extending it upwards (or outwards – depends how you look at it) to reflect the extended enterprise context in which most organizations “live” today. This involves taking concepts which we already apply to the single enterprise and applying them to a world we don’t control, where multiplicity is the rule and in which our objective is to be an equal partner. This gives rise to relationships, which are both complex and shifting. I would argue that one consequence is that we need to put the emphasis on capturing the entirety of the situation, so we can understand its dynamics and reach (breadth), and we need to avoid the distraction of those details, which we know can and will change without our being consulted (anyone see a similarity to Cloud here?). Another part of what Tom is doing is a mapping with Archimate. I don’t know whether Tom sees it exactly the way I do, but I think one of the advantages is that it combines the impressionist approach with a standardized modeling technique and allows us to provide detail where it’s meaningful and useful. And what it also does is provide a semi-formalized way of using techniques coming from a different discipline within (or along with) familiar EA frameworks. Well, I say “does” but I should say “will do”. It’s work in progress, just like Scatter. Just like TOGAF® Next. You can contribute to these things, influence them or adapt them to your own purposes. You can read and leave them aside but at least you’ll have thought about it. And that in and of itself will enrich your practice.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting 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. 

1 Comment

Filed under Enterprise Architecture, TOGAF®

How strategic planning relates to Enterprise Architecture

By Serge Thorn, Architecting the Enterprise

TOGAF® often refers to Strategic Planning without specifying the details of what it consists of. This document explains why there is a perfect fit between the two.

Strategic Planning means different things to different people. The one constant is its reference to Business Planning which usually occurs annually in most companies. One of the activities of this exercise is the consideration of the portfolio of projects for the following financial year, also referred to as Project Portfolio Management (PPM). This activity may also be triggered when a company modifies its strategy or the priority of its current developments.

Drivers for Strategic Planning may be

  • New products or services
  • A need for greater business flexibility and agility
  • Merger & acquisition
  • Company’s reorganization
  • Consolidation of manufacturing plants, lines of business, partners, information systems
  • Cost reduction
  • Risk mitigation
  • Business process management initiatives
  • Business process outsourcing
  • Facilities outsourcing or insourcing
  • Off-shoring

Strategic Planning as a process may include activities such as:

1. The definition of the mission and objectives of the enterprise

Most companies have a mission statement depicting the business vision, the purpose and value of the company and the visionary goals to address future opportunities. With that business vision, the board of the company defines the strategic (e.g. reputation, market share) and financial objectives (e.g. earnings growth, sales targets).

2. Environmental analysis

The environmental analysis may include the following activities:

  • Internal analysis of the enterprise
  • Analysis of the enterprise’s industry
  • A PEST Analysis (Political, Economic, Social, and Technological factors). It is very important that an organization considers its environment before beginning the marketing process. In fact, environmental analysis should be continuous and feed all aspects of planning, identify the strengths and weaknesses, the opportunities and threats (SWOT)

3. Strategy definition

Based on the previous activities, the enterprise matches strengths to opportunities and addressing its weaknesses and external threats and elaborate a strategic plan. This plan may then be refined at different levels in the enterprise. Below is a diagram explaining the various levels of plans.

To build that strategy, an Enterprise Strategy Model may be used to represent the Enterprise situation accurately and realistically for both past and future views. This can be based on Business Motivation Modeling (BMM) which allows developing, communicating and managing a Strategic Plan. Another possibility is the use of Business Model Canvas which allows the company to develop and sketch out new or existing business models. (Refer to the work from Alexander Osterwalder).

The model’s analyses should consider important strategic variables such as customers demand expectations, pricing and elasticity, competitor behavior, emissions regulations, future input, and labor costs.

These variables are then mapped to the main important business processes (capacity, business capabilities, constraints), and economic performance to determine the best decision for each scenario. The strategic model can be based on business processes such as customer, operation or background processes. Scenarios can then are segmented and analyzed by customer, product portfolio, network redesign, long term recruiting and capacity, mergers and acquisitions to describe Segment Business Plans.

4. Strategy Implementation

The selected strategy is implemented by means of programs, projects, budgets, processes and procedures. The way in which the strategy is implemented can have a significant impact on whether it will be successful, and this is where Enterprise Architecture may have a significant role to play. Often, the people formulating the strategy are different from those implementing it. The way the strategy is communicated is a key element of the success and should be clearly explained to the different layers of management including the Enterprise Architecture team.

To support that strategy, different levels or architecture can be considered such as strategic, segment or capability architectures.

This diagram below illustrates different examples of new business capabilities linked to a Strategic Architecture.

It also illustrates how Strategic Architecture supports the enterprise’s vision and the strategic plan communicated to an Enterprise Architecture team.

Going to the next level allows better detail the various deliverables and the associated new business capabilities. The segment architecture maps perfectly to the Segment Business Plan.

5. Evaluation and monitoring

The implementation of the strategy must be monitored and adjustments made as required.

Evaluation and monitoring consists of the following steps:

  • Definition of KPIs, measurement and metrics
  • Definition of target values for these KPIs
  • Perform measurements
  • Compare measured results to the pre-defined standard
  • Make necessary changes

Strategic Planning and Enterprise Architecture should ensure that information systems do not operate in a vacuum. At its core, TOGAF® 9 uses/supports a strong set of guidelines that were promoted in the previous version, and have surrounded them with guidance on how to adopt and apply TOGAF® to the enterprise for Strategic Planning initiatives. The ADM diagram below clearly indicates the integration between the two processes.

The company’s mission and vision must be communicated to the Enterprise Architecture team which then maps Business Capabilities to the different Business Plans levels.

Many Enterprise Architecture projects are focused at low levels but should be aligned with Strategic Corporate Planning. Enterprise Architecture is a critical discipline, one Strategic Planning mechanism to structure an enterprise. TOGAF® 9 is without doubt an effective framework for working with stakeholders through Strategic Planning and architecture work, especially for organizations who are actively transforming themselves.

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.

2 Comments

Filed under Enterprise Architecture, TOGAF®

PODCAST: Embracing EA and TOGAF® aids companies in improving innovation, market response and governance

By Dana Gardner, Interabor Solutions

Listen to this recorded podcast here: BriefingsDirect-How to Leverage Advanced TOGAF 9 Use for Business Benefits

The following is the transcript of a sponsored podcast panel discussion on how to leverage advanced concepts in TOGAF® for business benefits, in conjunction with the The Open Group Conference, Austin 2011.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion in conjunction with the latest Open Group Conference in Austin, Texas, the week of July 18, 2011. We’ve assembled a panel to examine the maturing use of TOGAF. That’s The Open Group Architecture Framework, and how enterprise architects and business leaders are advancing and exploiting the latest Framework, Version 9. We’ll further explore how the full embrace of TOGAF, its principles and methodologies, are benefiting companies in their pursuit of improved innovation, responsiveness to markets, and operational governance. Is enterprise architecture (EA) joining other business transformation agents as a part of a larger and extended strategic value? How? And what exactly are the best practitioners of TOGAF getting for their efforts in terms of business achievements?

Here with us to delve into advanced use and expanded benefits of EA frameworks and what that’s doing for their user organizations is Chris Forde, Vice President of Enterprise Architecture and Membership Capabilities for The Open Group, based in Shanghai. Welcome, Chris.

Chris Forde: Good morning, Dana.

Gardner: We’re also here with Jason Uppal. He is the Chief Architect at QR Systems, based in Toronto. Welcome, Jason.

Jason Uppal: Thank you, Dana.

Gardner: Jason, let’s cut to the quick here. We hear an awful lot about architecture. We hear about planning and methodologies, putting the right frameworks in place, but is TOGAF having an impact on the bottom line in the organizations that are employing it?

Uppal: One of the things with a framework like a TOGAF is that, on the outside, it’s a framework. At the same time, when you apply this along with the other disciplines, it’s making big difference in the organization, partially it’s because it’s allowing the IT organizations to step up to the plate within the core enterprise as a whole and ask how they can actually exploit the current assets that they already have. And secondly, how do they make sure the new assets that they do bring into the organization are aligned to the business needs.

One of the examples where EA has a huge impact in many of the organizations that I have experience with is that, with key EA methods, we’re able to capture the innovation that exists in the organization and make that innovation real, as opposed to just suggestions that are thrown in a box, and nobody ever sees them.

Gardner: What is it about capturing that innovation that gets us to something we can measure in terms of an achievable bottom-line benefit?

Evolve over time

Uppal: Say you define an end-to-end process using architecture development method (ADM) methods in TOGAF. What it does is give me a way to capture that innovation at the lowest level and then evolve it over time. Those people who are part of the innovation at the beginning see their innovation or idea progressing through the organization, as the innovation gets aligned to value statements, and value statements get aligned to their capabilities, and the strategies, and the projects, and hence to the end of the day.

Therefore, if I make a suggestion of some sort, that innovation or idea is seen throughout the organization through the methods like ADM, and the linkage is explicit and very visible to the people. Therefore, they feel comfortable that their ideas are going somewhere, they are just not getting stuck.

Forde: There’s an additional point here, Dana, to underscore the answer that Jason gave to your question. In the end result, what you want to be seeing out of your architectural program is moving the KPIs for the business, the business levers that they are expecting to be moved out. If that is related to cost reduction or is related to top-line numbers or whatever, that explicit linkage through to the business levers in an architecture program is critical.

Gardner: Chris, you have a good view on the global markets and the variability of goals here. Many companies are looking to either cut cost or improve productivity. Others are looking to expand. Others are looking to manage how to keep operations afloat. There are so many different variables. How do things like the TOGAF 9 and EA have a common benefit to all of those various pursuits? What is the common denominator that makes EA so powerful?

Forde: Going back to the framework reference, what we have with TOGAF 9 is a number of assets, but primarily it’s a tool that’s available to be customized, and it’s expected to be customized.

If you come to the toolset with a problem, you need to focus the framework on the area that’s going to help you get rapid value to solving your particular problem set. So once you get into that particular space, then you can look at migrating out from that entry point, if that’s the approach, to expanding your use of the framework, the methods, the capabilities, that are implicit and explicit in the framework to address other areas. You can start at the top and work your way down through the framework, from this kind of über value proposition, right down through delivery to the departmental level or whatever. Or, you can come into the bottom, in the infrastructure layer, in IT for example, and work your way up. Or, you can come in at the middle. The question is what is impeding your company’s growth or your department’s growth, if those are the issues that are facing you.

One of the reasons that this framework is so useful in so many different dimensions is that it is a framework. It’s designed to be customized, and is applicable to many different problems.

Gardner: Back to you, Jason. When we think about a beginning effort, perhaps a crawl-walk- run approach to EA and TOGAF, the promise is that further development, advancement, understanding, implementation will lead to larger, more strategic goals.

Let’s define what it means to get to that level of maturity. When we think about an advanced user of TOGAF, what does that mean? Then, we’ll get into how they can then leverage that to further goals. But, what do we really mean by an advanced user at this point?

Advanced user

Uppal: When we think about an advanced user, in our practice we look at it from different points of view and ask what value I’m delivering to the organization. It could very well be delivering value to a CTO in the organization. That is not to say that’s not an advanced user, because that’s strictly focused on technology.

But then, the CTO focus is that it allows us to focus on the current assets that are under deployment in the organization. How do you get the most out of them? So, that’s an advanced user who can figure out how to standardize and scale those assets into a scalable way so therefore they become reusable in the organization. As we move up the food chain from very technology-centric view of a more optimized and transformed scale, advanced user at that point is looking at and saying that now I have a framework like TOGAF, that advanced user has all these tools in their back pocket.

Now, depending on the stakeholder that they’re working with, be that a CEO, a CFO, or a junior manager in the line of business, I can actually focus them on defining a specific capability that they are working towards and create transition roadmaps. Once those transition roadmaps are established, then I can drive that through. An advanced user in the organization is somebody who has all these tools available to them, frameworks available to them, but at the same time, are very focused on a specific value delivery point in their scope.

One beauty of TOGAF is that, because we get to define what enterprise is and we are not told that we have to interview the CEO on day one, I can define an enterprise from a manager’s point of view or a CFO’s point of view and work within that framework. That to me is an advanced user.

Gardner: When we talk about applied architecture, what does that mean? How is it that we move from concept into execution?

Uppal: The frameworks that we have are well thought-out frameworks. So, it moves the conversation away from this framework debate and very quickly moves our conversation into what we do with it. When we talk about a framework like TOGAF, now I can look at and say that if I wanted to apply it now, I have an executive who has defined a business strategy, which typically is a two page PowerPoint presentation, sometimes accompanied by Excel. That’s a good starting point for an enterprise architect. Now, I use methods like TOGAF to define the capabilities in that strategy that they are trying to optimize, where they are, and what they want to transition to.

Very creative

This is where a framework allows me to be very creative, defining the capabilities and the transition points, and giving a roadmap to get to those transitions. That is the cleverness and cuteness of architecture work, and the real skills of an architect comes into, not in defining the framework, but defining the application of the framework to a specific business strategy.

Gardner: Jason, we mentioned that there is a great deal of variability in what different companies in different regions and in different industries need to accomplish, but one of the common questions I get a lot these days is what to outsource and what to manage internally and how to decide the boundaries between a core competency and extended outsourcing or hybrid computing types of models? How does the applied architecture come to the rescue, when this sort of question, which I think is fundamental to an enterprise, comes up?

Uppal: That’s a great question. That’s one of the area where if architects do their job well, we can help the organization move much further along. Because, what we do in the business space, and we have done it many times with the framework, is to look at the value chain of the organization. And looking at the value chain, then to map that out to the capabilities required.

Once we know those capabilities, then I can squarely put that question to the executives and say, “Tell me which capability you want to be the best at. Tell me what capability you want to lead the market in. And, tell me which capability you want to be mediocre and just be at below the benchmark in industry.” Once I get an understanding of which capability I want to be the best at, that’s where I want to focus my energy. Those ones that I am prepared to live with being mediocre, then I can put another strategy into place and ask how I outsource these things, and focus my outsourcing deal on the cost and service.

This is opposed to having very confused contract with the outsourcer, where one day I’m outsourcing for the cost reasons. The other day, I’m outsourcing for growth reasons. It becomes very difficult for an organization to manage the contracts and bend it to provide the support. That conversation, at the beginning, is getting executives to commit to which capability they want to be best at. That is a good conversation for an enterprise architect.

My personal experience has been that if I get a call back from the executive, and they say they want to be best at every one of them, then I say, “Well, you really don’t have a clue what you are talking about. You can’t be super fast and super good at every single thing that you do.”

Gardner: So making those choices is what’s critical. Some of the confusion I also hear about in the field is how to do a cost-benefit analysis about what processes I might keep internal, versus either hybrid or external source processes?

Is there something about the applied architecture and TOGAF 9 that sets up some system of record or methodology approach that allows that cost-benefit analysis of these situations to be made in advance? Is there anything that the planning process brings to the table in trying to make proper decisions about sourcing?

Capability-based planning

Uppal: Absolutely. This is where the whole of our capability-based planning conversation is. It was introduced in TOGAF 9, and we got more legs to go into developing that concept further, as we learn how best to do some of these things.

When I look at a capability-based planning, I expect my executives to look at it from a point of view and ask what are the opportunities and threats. What it is that you can get out there in the industry, if you have this capability in your back pocket? Don’t worry about how we are going to get it first, let’s decide that it’s worth getting it.

Then, we focus the organization into the long haul and say, well, if we don’t have this capability and nobody in the industry has this capability, if we do have it, what will it do for us? It provides us another view, a long-term view, of the organization. How are we going to focus our attention on the capabilities?

One of the beauties of doing EA is, is that when we start EA at the starting point of a strategic intent, that gives us a good 10-15 year view of what our business is going to be like. When we start architecture at the business strategy level, that gives us a six months to five-year view.

Enterprise architects are very effective at having two views of the world — a 5, 10, or 15 year view of the world, and a 6 months to 3 year view of the world. If we don’t focus on the strategic intent, we’ll never know what is possible, and we would always be working on what is possible within our organization, as opposed to thinking of what is possible in the industry as a whole.

Gardner: So, in a sense, you have multiple future tracks or trajectories that you can evaluate, but without a framework, without an architectural approach, you would never be able to have that set of choices before you.

Chris Forde, any thoughts on what Jason’s been saying in terms of the sourcing and cost benefits and risks analysis that go into that?

Forde: In the kinds of environment that most organizations are operating in — government, for- profit, not-for-profit organizations — everybody is trying to understand what it is they need to be good at and what it is their partners are very good at that they can leverage. Their choices around this are of course critical.

One of the things that you need to consider is that if you are going to give x out and have the power to manage that and operate whatever it is, whatever process it might be, what do you have to be good at in order to make them effective? One of the things you need to be good at is managing third parties. One of the advanced uses of an EA is applying the architecture to those management processes. In the maturity of things you can see potentially an effective organization managing a number of partners through an architected approach to things. So when we talked about what do advanced users do, what I am offering is that an advanced use of EA is in the application of it to third-party management.

Gardner: So the emphasis is on the process, not necessarily who is executing on that process?

Framework necessary

Forde: Correct, because you need a framework. Think about what most major Fortune 500 companies in the United States do. They have multiple, multiple IT partners for application development and potentially for operations. They split the network out. They split the desktop out. This creates an amazing degree of complexity around multiple contracts. If you have an integrator, that’s great, but how do you manage the integrator?

There’s a whole slew of complex problems. What we’ve learned over the years is that the original idea of “outsourcing,” or whatever the term that’s going to be used, we tend to think of that in the abstract, as one activity, when in fact it might be anywhere from 5-25 partners. Coordinating that complexity is a major issue for organizations, and taking an architected approach to that problem is an advanced use of EA.

Gardner: So stated another way, Jason, the process is important, but the management of processes is perhaps your most important core competency. Is that fair, and how does EA support that need for a core competency of managing processes across multiple organizations?

Uppal: That’s absolutely correct. Chris is right. For example, there are two capabilities an organization decided on, one that they wanted to be very, very good at.

We worked with a large concrete manufacturing company in the northern part of the country. If you’re a concrete manufacturing company, your biggest cost is the cement. If you can exploit your capability to optimize the cement and substitute products with the chemicals and get the same performance, you can actually get a lot more return and higher margins for the same concrete.

In this organization, the concrete manufacturing process itself was core competency. That had to be kept in-house. The infrastructure is essential to make the concrete, but it wasn’t the core competency of the organization. So those things had to be outsourced. In this organization we have to build a process — how to manage the outsourcer and, at the same time, have a capability and a process. Also, how to become best concrete manufacturers. Those two essential capabilities were identified.

An EA framework like TOGAF actually allows you to build both of those capabilities, because it doesn’t care. It just thinks, okay, I have a capability to build, and I am going to give you a set of instructions, the way you do it. The next thing is the cleverness of the architect — how he uses his tools to actually define the best possible solutions.

Gardner: Of course, it’s not just enough to identify and implement myriad sourcing or complex sourcing activities, but you need to monitor and have an operational governance oversight capability as well. Is there something in TOGAF 9 specifically that lends itself to taking this into the operational and then creating ongoing efficiencies as a result?

Uppal: Absolutely, because this is one of the areas where in ADM, when we get back to our implementation of governance, and post implementation of governance, value realization, how do we actually manage the architecture over the life of it? This is one of the areas where TOGAF 9 has done a considerably good job, and we’ve still got a long way to go in how we actually monitor and what value is being realized.

Very explicit

Our governance model is very explicit about who does what and when and how you monitor it. We extended this conversation using TOGAF 9 many times. At the end, when the capability is deployed, the initial value statement that was created in the business architecture is given back to the executive who asked for that capability.

We say, “This is what the benefits of these capabilities are and you signed off at the beginning. Now, you’re going to find out that you got the capability. We are going to pass this thing into strategic planning next year, because for next year’s planning starting point, this is going to be your baseline.” So not only is the governance just to make sure it’s via monitoring, but did we actually get the business scores that we anticipated out of it.

Gardner: Another area that’s of great interest to me nowadays is looking at the IT organization as they pursue things like Cloud, software as a service (SaaS), and hybrid models. Do they gather a core competency at how to manage these multiple partners, as Chris pointed out, or does another part of the company that may have been dealing with outsourcing at a business process level teach the IT department how to do this?

Any sense from either of our panelists on whether IT becomes a leader or a laggard in how to manage these relationships, and how important is managing the IT element of that in the long run? Let’s start with you, Jason.

Uppal: It depends on the industry the IT is in. For example, if you’re an organization that is very engineering focused, engineers have a lot more experience managing outsourcing deals than IT organizations do. In that case, the engineering leads this conversation.

But in most organizations, which are service-oriented organizations, engineering has not been a primary discipline, and IT has a lot of experience managing outside contracts. In that case, the whole Cloud conversation becomes a very effective conversation within the IT organization.

When we think about cloud, we have actually done Cloud before. This is not a new thing, except that before we looked at it from a hosting point of view and from a SaaS point of view. Now, cloud is going in a much further extended way, where entire capability is provided to you. That capability is not only that the infrastructure is being used for somebody else, but the entire industry’s knowledge is in that capability. This is becoming a very popular thing, and rightfully so, not because it’s a sexy thing to have. In healthcare, especially in countries where it’s a socialized healthcare and it’s not monopolized, they are sharing this knowledge in the cloud space with all the hospitals. It’s becoming a very productive thing, and enterprise architects are driving it, because we’re thinking of capabilities, not components.

Gardner: Chris Forde, similar question. How do you see the role of IT shifting or changing as a result of the need to manage more processes across multiple sources?

Forde: It’s an interesting question. I tend to agree with the earlier part of Jason’s response. I am not disagreeing with any of it, actually, but the point that he made about it is that it’s a “it depends” answer.

IT interaction

Under normal circumstances the IT organizations are very good at interacting with other technology areas of the business. From what I’ve seen with the organizations I have dealt with, typically they see slices of business processes, rather than the end-to-end process entirely. Even within the IT organizations typically, because of the size of many organizations, you have some sort of division of responsibilities. As far as Jason’s emphasis on capabilities and business processes, of course the capabilities and processes transcend functional areas in an organization.

To the extent that a business unit or a business area has a process owner end to end, they may well be better positioned to manage the BPMO type of things. If there’s a heavy technology orientation around the process outsourcing, then you will see the IT organization being involved to one extent or another.

The real question is, where is the most effective knowledge, skill, and experience around managing these outsourcing capabilities? It may be in the IT organization or it may be in the business unit, but you have to assess where that is.

That’s one of the functions that the architecture approaches. You need to assess what it is that’s going to make you successful in this. If what you need happens to be in the IT organization, then go with that ability. If it is more effective in the business unit, then go with that. And perhaps the answer is that you need to combine or create a new functional organization for the specific purpose of meeting that activity and outsource need.

I’m hedging a little bit, Dana, in saying that it depends.

Gardner: It certainly raises some very interesting issues. At the same time that we’re seeing this big question mark around sourcing and how to do that well, we’re also in a period where more organizations are being data-driven and looking to have deeper, more accessible, and real-time analytics applied to their business decisions. Just as with sourcing, IT also has an integral role in this, having been perhaps the architects or implementators of warehousing, data marts, and business intelligence (BI).

Back to you Jason. As we enter into a phase where organizations are also trying to measure and get scientific and data-driven about their decisions, how does IT, and more importantly, how does TOGAF and EA come to help them do that?

Uppal: We have a number of experiences like that, Dana. One is a financial services organization. The entire organization’s function is that they manage some 100-plus billion dollars worth of assets. In that kind of organization, all the decision making process is based on the data that they get. And 95 percent of the data is not within the organization. It is vendor data that they’re getting from outside.

So in that kind of conversation, we look and say that the organization needs a capability to manage data. Once we define a capability, then we start putting metrics on this thing. What does this capability need to be able to do?

In this particular example, we put a metric on this and said that the data gets identified in the morning, by the afternoon we bring it into the organization, and by the end of the day we get rid of it. That’s how fast the data has to be procured, transformed into the organization, brought it in, and delivered it to end-use. That end-user makes the decision whether we will never look at the data again.

Data capability

Having that fast speed of data management capability in the organization, and this is one of the areas where architects can take a look at, this is the capability you need. Now I can give you a roadmap to get to that capability.

Gardner: Chris Forde, how do you see the need for a data-driven enterprise coincide with IT and EA?

Forde: For most, if not all, companies, information and data are critical to their operation and planning activities, both on a day-to-day basis, month-to-month, annually, and in longer time spans. So the information needs of a company are absolutely critical in any architected approach to solutioning or value-add type of activities.

I don’t think I would accept the assumption that the IT department is best-placed to understand what those information needs are. The IT organization may be well-placed to provide input into what technologies could be applied to those problems, but if the information needs are normally being applied to business problems, as opposed to technology problems, I would suggest that it is probably the business units that are best-placed to decide what their information needs are and how best to apply them.

The technologist’s role, at least in the model I’m suggesting, is to be supportive in that and deliver the right technology, at the right time, for the right purpose.

Gardner: Then, how would a well-advanced applied architecture methodology and framework help those business units attain their information needs, but also be in a position to exploit IT’s helping hand when needed?

Forde: It’s mostly providing the context to frame the problem in a way that it can be addressed, chunked down to reasonable delivery timeframes, and then marshaling the resources to bring that to reality.

From a pure framework and applied methodology standpoint, if you’re coming at it from an idealized situation, you’re going to be doing it from a strategic business need and you’re going to be talking to the business units about what their capability and functional needs are. And at that time, you’re really in the place of what business processes they’re dealing with and what information they need in order to accomplish what the particular set of goals is.

This is way in advance of any particular technology choice being made. That’s the idealized situation, but that’s typically what most frameworks, and in particular, the TOGAF 9 Framework from The Open Group, would go for.

Gardner: We’re just beginning these conversations about advanced concepts in EA and there are going to be quite a bit more offerings and feedback and collaboration around this subject at The Open Group Conference in Austin. Perhaps before we sign off, Jason, you can give us a quick encapsulation of what you will be discussing in terms of your presentation at the conference.

Uppal: One of the things that we’ve been looking at from the industry’s point of view is saying that this conversation around the frameworks is a done deal now, because everybody accepted that we have good enough frameworks. We’re moving to the next phase of what we do with these frameworks.

In our future conferences, we’re going to be addressing that and saying what people are specifically doing with these frameworks, not to debate the framework itself, but the application of it.

Continuous planning

In Austin we’ll be looking at how we’re using a TOGAF framework to improve ongoing annual business and IT planning. We have a specific example that we are going to bring out where we looked at an organization that was doing once-a-year planning. That was not a very effective way for the organizations. They wanted to change it to continuous planning, which means planning that happens throughout the year.

We identified four or five very specific measurable goals that the program had, such as accuracy of your plan, business goals being achieved by the plan, time and cost to manage and govern the plan, and stakeholders’ satisfaction. Those are the areas that we are defining as to how the TOGAF like framework will be applied to solve a specific problem like enterprise planning and governance.

That’s something we will be bringing to our conference in Austin and that event will be held on a Sunday. In the future, we’ll be doing a lot more of those specific applications of a framework like a TOGAF to a unique set of problems that are very tangible and they very quickly resonate with the executives, not in IT, but in the entire organization.

Forde: Can I follow along with a little bit of a plug here, Dana.

Gardner: Certainly.

Forde: Jason is going to be talking as a senior architect on the applied side of TOGAF on this Sunday. For the Monday plenary, this is basically the rundown. We have David Baker, a Principal from PricewaterhouseCoopers, talking about business driven architecture for strategic transformations.

Following that, Tim Barnes, the Chief Architect at Devon Energy out of Canada, covering what they are doing from an EA perspective with their organization.

Then, we’re going to wrap up the morning with Mike Walker, the Principal Architect for EA Strategy and Architecture at Microsoft, talking about IT Architecture to the Enterprise Architecture.

This is a very powerful lineup of people addressing this business focus in EA and the application of it for strategic transformations, which I think are issues that many, many organizations are struggling with.

Gardner: Looking at, again, the question I started us off with, how do TOGAF and EA affect the bottom line? We’ve heard about how it affects the implementation for business transformation processes. We’ve talked about operational governance. We looked at how sourcing, business process management and implementation, and ongoing refinement are impacted. We also got into data and how analytics and information sharing are affected. Then, as Jason just mentioned, planning and strategy as a core function across a variety of different types of business problems.

So, I don’t think we can in any way say that there’s a minor impact on the bottom line from this. Last word to you, Jason.

Uppal: This is a time now for the enterprise architects to really step up to the plate and be accountable for real performance influence on the organization’s bottom line.

If we can improve things like exploiting assets better today than what we have, improve our planning program, and have very measurable and unambiguous performance indicator that we’re committing to, this is a huge step forward for enterprise architects and moving away from technology and frameworks to real-time problems that resonate with executives and align to business and in IT.

Gardner: Well, great. You’ve been listening to a sponsored podcast discussion in conjunction with The Open Group Conference in Austin, Texas, the week of July 18, 2011.

I would like to thank our guests. We have been joined by Chris Forde, Vice President of Enterprise Architecture and Membership Capabilities for The Open Group. Thanks, Chris.

Forde: Thanks, Dana.

Gardner: And also Jason Uppal. He is the Chief Architect at QR Systems. Thank you, Jason.

Uppal: Thank you, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks for joining, and come back next time.

Jason Uppal will be presenting “Advanced Concepts in Applying TOGAF 9” at The Open Group Conference, Austin, July 18-22. Join us for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Copyright The Open Group 2011. All rights reserved.

Dana Gardner is the Principal Analyst at Interarbor Solutions, which identifies and interprets the trends in Services-Oriented Architecture (SOA) and enterprise software infrastructure markets. Interarbor Solutions creates in-depth Web content and distributes it via BriefingsDirect™ blogs, podcasts and video-podcasts to support conversational education about SOA, software infrastructure, Enterprise 2.0, and application development and deployment strategies.

Comments Off

Filed under Enterprise Architecture, TOGAF®

EA Fundamentalism

By Stuart Boardman, Getronics

It’s an unfortunate fact that when times get tough, the tough, rather than get going, tend to pick on other people. What we see is that most formal and informal groups tend to turn inwards and splinter into factions, each possessing the only true gospel. When times are good, we’re all too busy doing what we actually want to do to want to waste time sniping at other folks.

Maybe this isn’t the reason but it strikes me that in the EA blogosphere at the moment (e.g. the EA group on LinkedIn) every discussion seems to deteriorate into debate about what the proper definition of EA is (guess how many different “right answers” there are) or which of TOGAF® or Zachman or <insert your favourite framework here> is the (only) correct framework or why all of them are totally wrong, or worse still, what the correct interpretation of the minutiae of some aspect of framework X might be.

Perhaps the only comfort we can draw from the current lack of proper recognition of EA by the business is the fact that the Zachmanites are actually not firing bullets at the Rheinlanders (or some other tribe). Apart from the occasional character assassination, it’s all reasonably civilized. There’s just not enough to lose. But this sort of inward looking debate gets us nowhere.

I use TOGAF® . If you use another framework that’s better suited to your purpose, I don’t have a problem with that. I use it as framework to help me think. That’s what frameworks are for. A good framework doesn’t exclude the possibility that you use other guidance and insights to address areas it doesn’t cover. For example, I make a lot of use of the Business Model Canvas from Osterwalder and Pigneur and I draw ideas from folks like Tom Graves (who in turn has specialized the Business Model Canvas to EA). A framework (and any good methodology) is not a cookbook. If you understand what it tries to achieve, you can adapt it to fit each practical situation. You can leave the salt out. You can even leave the meat out! There are some reasonable criticisms of TOGAF® from within and outside The Open Group. But I can use TOGAF® with those in mind. And I do. One of the things I like about The Open Group is that it’s open to change – and always working on it. So the combination of The Open Group and TOGAF® and the awareness of important things coming from other directions provides me with an environment that, on the one hand, encourages rigour, and on the other, constantly challenges my assumptions.

It’s not unusual in my work that I liaise with other people officially called Enterprise Architects. Some of these folks think EA is only about IT. Some of them think it’s only about abstractions. I also work with Business Architects and Business Process Architects and Business Strategists and Requirements Engineers and….. I could go on for a very long time indeed. All of these people have definitions of their own scope and responsibilities, which overlap quite enough to allow not just for fundamentalism but also serious turf wars. Just as out there in the real world, the fundamentalists and those who define their identity by what they are not are the ones who start wars which everyone loses.

The good news is that just about enough of the time enough of these folks are happy to look at what we are all trying to achieve and who can bring what to the party and will work together to produce a result that justifies our existence. And every time that happens I learn new things – things that will make a me a better Enterprise Architect. So if I get noticeably irritated by the religious disputes and respond a bit unreasonably in web forum debates, I hope you’ll forgive me. I don’t like war.

By the way, credit for the “fundamentalism” analogy goes to my friend and former colleague, François Belanger. Thanks François.

Enterprise Architecture will be a major topic of discussion at The Open Group Conference, Austin, July 18-22. Join us for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting 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.

4 Comments

Filed under Enterprise Architecture, TOGAF®

TOGAF® Certification Success: More than 7,000 individuals certified from over 50 countries

By Andrew Josey, The Open Group

Certification is a core competence of The Open Group and key to the successful rollout of our standards. TOGAF®, an Open Group standard, is the de facto global standard for Enterprise Architecture. The fast adoption of TOGAF 9 and demand for its certification program by architecture professionals and their employers is indicative of the value to be gained from trusted, globally accepted standards supported through certification.

As one of the team who developed TOGAF 9, I regularly track the statistics to monitor the take-up and adoption worldwide. Certifications within the TOGAF 9 program are currently growing at over one thousand individuals per quarter. As of June 3rd there were 7,200 individuals certified from more than 50 countries.

Of particular interest is to look at the countries adopting TOGAF. The top five includes the UK, The Netherlands, The USA, Australia and South Africa.

(Note 1: Data as of June 3rd 2011. Other countries outside the top 30 include (in order) Spain, Ireland, Austria, Malaysia, Kuwait, Jordan, Portugal, Russia, Costa Rica, Taiwan, Hungary, Oman, Nigeria, Botswana, Luxembourg, Indonesia, Sri Lanka, Egypt, Chile, Thailand, South Korea and Peru.)

There are 34 TOGAF 9 training partners worldwide and 37 accredited TOGAF 9 courses. More information on TOGAF 9 Certification, including the directory of Certified People and official accredited training course calendar, can be obtained from The Open Group website.

As part of the ongoing process of “Making Standards Work®”, we will be defining new certification standards and policy in the member meetings at The Open Group Conference, Austin, Texas (July 18-22, The Four Seasons Hotel). This will include the development of certification for the ArchiMate® standard and the addition of tools certification for TOGAF® Version 9.

If you are able to join us in Austin in July, I hope you will be able to also join us at the member meetings to work on building the next certification standards. If you are not yet a member then I hope you will attend the conference itself and network with the members to find out more and consider joining us at The Open Group.

Andrew Josey is Director of Standards within The Open Group, responsible for the Standards Process across the organization. Andrew leads the standards development activities within The Open Group Architecture Forum, including the development and maintenance of TOGAF® 9, and the TOGAF® 9 People certification program. He also chairs the Austin Group, the working group responsible for development and maintenance of the POSIX 1003.1 standard that forms the core volumes of the Single UNIX® Specification. He is the ISO project editor for ISO/IEC 9945 (POSIX). He is a member of the IEEE Computer Society’s Golden Core and is the IEEE P1003.1 chair and the IEEE PASC Functional chair of Interpretations. Andrew is based in the UK.

2 Comments

Filed under Enterprise Architecture, TOGAF®