Tag Archives: ArchiMate

The Open Group Reaches 500th Membership Milestone

By The Open Group

To reach the number 500 in anything is a significant achievement. In business, the top companies in the world vie to be part of the Fortune 500 or the S&P 500. In automobile racing, top annual competitions for racers—the Indy 500 and Daytona 500—require participants to drive 500 laps around a racetrack. Even American baseball has its own 500 Homerun Club, which includes legendary hitters such as Babe Ruth and Hank Aaron who achieved more than 500 homeruns in a lifetime.

We’re pleased to announce that The Open Group has also joined the ranks of those that can mark a milestone of 500. We welcome Universidad Continental to The Open Group, which has the distinction of being our 500th membership. Universidad Continental, in Peru, is the first university member of The Open Group in South America.

Although The Open Group was formed over 20 years ago, our organization has experienced significant uptick during the past few years. In a global economy where businesses have become ever-more dependent on technology, there is more need for technology standards today than ever before. With technologies such as Big Data, the Cloud and the Internet of Things, our mission of Boundaryless Information Flow™ to break down silos among and within organizations has never been more important. Companies are increasingly recognizing the importance of how open standards can help them transform their business and achieve their goals—this milestone and our recent help prove that.

Over these past 20 years, The Open Group has seen many other significant milestones—the 40th anniversary of the Single UNIX® specification, the rapid growth of certification programs such TOGAF® 9,, which has reached over 47,000 certifications worldwide, and the ArchiMate® Certification for People program, which has more than 2,500 individual certifications. (UNIX®, TOGAF® and ArchiMate® are standards of The Open Group.) But to reach our 500th membership of The Open Group as an organization is particularly memorable. It shows that our approach of developing consensus-driven requirements and policies and sharing best practices is resonating in a time where rapid change is the only norm when it comes to technology. And in times of uncertainty like these, open standards are one way that companies can gain stability while maintaining the flexibility and agility they need to keep moving forward and to advance with the industry.

As a consortia, The Open Group would be nothing without its members—the vendors, customers, systems and solutions suppliers, integrators, consultants, government, academia and researchers that span the entire IT community. The collaborative work the membership continues to do through the Forums and Work Groups to bring standards and certifications to both the global IT community and vertical industries is helping to shape the future of enterprise integration. As we continue to create standards that touch every part of the industry—from Enterprise Architecture to Security, IT management, Open Platform 3.0™, the supply chain, IT4IT™, Healthcare and embedded systems—we look forward to the continued support of our members and to future member milestones.


Filed under 500th membership, Boundaryless Information Flow™, Information Technology, Standards, The Open Group

Balancing Complexity and Continuous Improvements – A Case Study from the Automotive Industry

By The Open Group


The automotive industry is currently facing massive challenges. For the past 30-40 years, automakers have faced stiff competition in the marketplace, as well as constant pressure to make more innovative and efficient vehicles while reducing the costs to manufacture them.

At the same time, current technological advances are making the industry—and the technology inside automobiles—increasingly complex. Digitalization is also affecting not only how automobiles work but is forcing changes in the manufacturing process and in how automakers run their businesses. With technology now touching nearly every part of the business and how it functions, the IT landscape for automakers is becoming a web of interconnected systems running both inside and outside of the business.

In addition, with computing systems becoming a more integral part of the systems that run vehicles, the lines between traditional IT functions and IT within cars themselves are beginning to blur. With trends such as Big Data and analytics, the Internet of Things and The Open Group Open Platform 3.0™ making cars, manufacturers, dealers and owners increasingly interconnected, automotive company IT departments are being forced to get involved in areas of the business, such as product development and maintenance, in ways they’ve never been before.

Between economic forces and technological change, automakers, like many businesses today, are facing massive upheaval and the need for major transformation in order to deal with levels of business complexity they’ve never seen before.


These challenges are very real for the automotive company in this case study. In addition to general economic and technological change, the company has gone through a number of transitions that have created additional infrastructure issues for the company. Over the past two decades, the company was bought then sold and bought again, bringing in two new owners and technological systems. Between the company’s original legacy IT systems and the systems brought in by its subsequent owners, the company’s IT landscape had become extremely complicated. In addition, the company is in the process of extending its footprint in the burgeoning Chinese market, a step that requires the company to invest in additional infrastructure in order to take advantage of China’s growing economic wealth to speed sales.

Between the company’s existing systems, the need to grow into emerging markets and increased digitalization across the company and its products, the company was in need of new approach to its overall architecture.


Although the company started early on to utilize IT to make the information flows across the company value chain as effective as possible, the existing IT environment had grown organically as the company had changed owners. In order to prepare themselves for an increasingly digital business environment, the company needed to address the increasing complexity of its systems without adding more complexity and while designing systems that could scale and run for the long haul.

Previously, the company had begun to consider using an Enterprise Architecture approach to address its growing complexity. Although the company had a number of solutions architects on staff, they soon realized that they needed a more holistic approach that could address the entire enterprise, not just the individual solutions that made up that IT landscape.

In an industry where time to market is of outmost importance there will always be challenges in balancing short-term solutions with strategic investments. As such, the company initially decided to invest in an Enterprise Architecture capability with the objective of addressing internal complexities to better understand and eventually deal with them. Because TOGAF®, an Open Group standard was seen as the de-facto industry standard for Enterprise Architecture it was the natural choice for the company to create its architecture framework. The majority of the Enterprise and solution Architects at the company were then trained and certified in TOGAF 9. Subsequently, TOGAF was adopted by the architecture community in the IT organization.

Within the IT department, TOGAF provided an ontology for discussing IT issues, and it also provided a foundation for the Enterprise Architecture repository. However, it was seen within the organization primarily as an IT architecture concern, not a framework for transformational change. The EA team decided that in order to really benefit from TOGAF and address the complexity challenges throughout the enterprise, they would need to prove that TOGAF could be used to add value throughout the entire organization and influence how changes were delivered to the IT landscape, as well as prove the value of a structured approach to addressing internal issues.

In order to prove that TOGAF could help with its overall transformation, the team decided to put together a couple of pilot projects within different business areas to showcase the benefits of using a structured approach to change. Due to a need to fix how the company sourced product components, the team decided to first pilot a TOGAF-based approach for its procurement process, since it was widely viewed as one of the most complex areas of the business.

A New Procurement Platform

The initial pilot project was aimed at modernizing the company’s procurement landscape. Although procurement is normally a fairly straightforward process, in the automotive business the intricacies and variations within the product structure, combined with a desire to control logistic costs and material flows, represented a major challenge for the company. In short, to save costs, the company only wanted to buy things they would actually use in the vehicle manufacturing process—no more, no less.

Over the years the IT supporting the company’s procurement process had become very fragmented due to investments in various point solutions and different partnerships that had been established over time. In addition, some parts of the system had been closed down, all of which made the information flow, including all the systems integrations that had occurred along the way, very difficult to map. There were also several significant gaps in the IT support of the procurement process that severely limited the transparency and integrity of the process.


Using TOGAF as an architecture framework and method in conjunction with ArchiMate®, an Open Group standard, for modelling notations and Sparx Enterprise Architect (EA) as a modelling tool, the team set out to establish a roadmap for implementing a new procurement platform. The TOGAF Architecture Development Method (ADM) was used to establish the architecture vision, and the architecture development phases were completed outlining a target architecture and a subsequent roadmap. No major adaptions were made to the ADM but the sourcing process for the platform was run in parallel to putting together the ADM, requiring an iterative approach to be used

As part of the roadmap, the following ArchiMate views were developed:

  • Motivation views
  • Information structure views
  • Baseline and target business process views
  • Baseline and target business function views
  • Baseline and target application function views
  • Baseline and target application landscape views
  • Baseline and target application usage views
  • Baseline and target infrastructure landscape views
  • Baseline and target infrastructure usage views

Each view was created using Sparx EA configured to facilitate the ADM process and acting as the architecture repository.

The TOGAF ADM provided a structured approach for developing a roadmap whose results could be traced back to the original vision. Having a well-defined methodology with clear deliverables and an artifacts meta-model made the work focused, and both TOGAF and ArchiMate were relatively easy to get buy in for.

The challenges for the project were mainly in one area—aligning the architecture development with the IT solution sourcing process. Because the company wanted to identify sourcing solutions early to assess costs and initiate negotiation, that emphasis pushed the project into identifying solutions building blocks very early on. In most cases, the output from the ADM process could directly be used as input for sourcing commercial of solutions; however, in this case, sourcing soon took precedence over the architecture development process. Usually moving through the ADM phases A to E can be done within a couple of months but evaluating solutions and securing funding within this company proved to be much more difficult and time consuming.


With a new procurement process roadmap in hand, the company has now begun to use the ADM to engage with and get Requests for Information (RFIs) from new suppliers. In addition, using TOGAF and ArchiMate to map the company’s procurement process and design an infrastructure roadmap helped to demystify what had been seen as an extremely complex procurement process. The project allowed the IT team to identify where the real complexities were in the process, many of which are at the component level rather than within the system itself. In addition, the company has been able to identify the areas that they need to prioritize as they begin their implementation process.


Initially TOGAF was seen as a silver bullet within the organization. However, companies must realize that the TOGAF methodology represents best practices, and there is still a need within any organization to have skilled, knowledgeable Enterprise Architects available and with the mandate to do the work.

As part of the project, the following benefits were provided by TOGAF:

  • Provided structure to the analysis
  • Ensured a holistic perspective for all domains
  • Kept the team focused on the outcome, definition, roadmap, etc.
  • Provided a good view into current and future data for the roadmap
  • Provided proven credibility for the analysis

ArchiMate added additional support by providing well-defined viewpoints, and Sparx EA is a cost effective modelling tool and repository that can easily be deployed to all stakeholder in an initiative.

However, within this particular organization, there were a number of challenges that need to be overcome, many of which can hinder the adoption of TOGAF. These challenges included:

  • Competing processes, methodologies and capabilities
  • Strong focus on solution design rather than architecture
  • Strong focus on project delivery tradition rather than managing programs and outcomes
  • Governance for solutions rather than architecture

Adopting Archimate proved to be more straightforward internally at this organization because it could be used to address immediate modelling needs but without requiring a coordinated approach around methodology and governance.

In cases such as this, it is probably best to sell the TOGAF and ArchiMate methodologies into the business organization as common sense solutions rather than as specific technology architecture methodologies. Although they may be presented as such to the EA community within the organization, it makes the decision process simpler not to oversell the technical solution, as it were, to the business, instead selling them the business benefits of the process.


Currently the company is beginning to move through the implementation phase of their roadmap. In addition, individuals throughout the organization have begun to regularly use ArchiMate as a tool for modeling different business areas within the organization. In addition the tools and concepts of TOGAF have been put into use successfully in several initiatives. The timeframe however for formally implementing a more comprehensive Enterprise Architecture Framework throughout other parts of the organization has been slowed down due to the company’s current focus on the release of new models. This is cyclical within the company and once the immediate focus on product delivery weakens, the need for consolidation and simplification will become a priority once again.

As with most companies, the key to a implementing a successful Enterprise Architecture capability within this company will come down to establishing a more effective partnership between the IT organization and the business organizations that IT is supporting. As such, for projects such as this, early engagement is key, and the IT organization must position itself not only as a delivery organization but a business partner that provides investment advice and helps minimize business risk through improved processes and technology based business transformation (as is prescribed by methodologies such as TOGAF and ArchiMate). This requires a unified view of the company mission and its business objectives and associated approaches from IT. Project managers, business analysts and Enterprise Architects must have a common view as to how to approach engagements for them to succeed. Without buy-in throughout the organization, the tools will only be useful techniques used by individuals and their real potential may not be realized.

Leave a comment

Filed under ArchiMate®, big data, digital technologies, EA, IoT, Open Platform 3.0, The Open Group, TOGAF

IT4IT™ Reference Architecture Version 2.0, an Open Group Standard

By The Open Group

1 Title/Current Version

IT4IT™ Reference Architecture Version 2.0, an Open Group Standard

2 The Basics

The Open Group IT4IT Reference Architecture standard comprises a reference architecture and a value chain-based operating model for managing the business of IT.

The IT Value Chain

The IT Value Chain has four value streams supported by a reference architecture to drive efficiency and agility. The four value streams are:

  • Strategy to Portfolio
  • Request to Fulfill
  • Requirement to Deploy
  • Detect to Correct

Each IT Value Stream is centered on a key aspect of the service model, the essential data objects (information model), and functional components (functional model) that support it. Together, the four value streams play a vital role in helping IT control the service model as it advances through its lifecycle.

The IT4IT Reference Architecture

  • Provides prescriptive guidance on the specification of and interaction with a consistent service model backbone (common data model/context)
  • Supports real-world use-cases driven by the Digital Economy (e.g., Cloud-sourcing, Agile, DevOps, and service brokering)
  • Embraces and complements existing process frameworks and methodologies (e.g., ITIL®, CoBIT®, SAFe, and TOGAF®) by taking a data-focused implementation model perspective, essentially specifying an information model across the entire value chain

3 Summary

The IT4IT Reference Architecture standard consists of the value chain and a three-layer reference architecture. Level 1 is shown below.

By The Open GroupThe IT4IT Reference Architecture provides prescriptive, holistic guidance for the implementation of IT management capabilities for today’s digital enterprise. It is positioned as a peer to comparable reference architectures such as NRF/ARTS, TMF Framework (aka eTOM), ACORD, BIAN, and other such guidance.

Together, the four value streams play a vital role in helping IT control the service model as it advances through its lifecycle:

By The Open GroupThe Strategy to Portfolio (S2P) Value Stream:

  • Provides the strategy to balance and broker your portfolio
  • Provides a unified viewpoint across PMO, enterprise 
architecture, and service portfolio
  • Improves data quality for decision-making
  • Provides KPIs and roadmaps to improve business communication

The Requirement to Deploy (R2D) Value Stream:

  • Provides a framework for creating, modifying, or sourcing a service
  • Supports agile and traditional development methodologies
  • Enables visibility of the quality, utility, schedule, and cost of 
the services you deliver
  • Defines continuous integration and deployment control points

The Request to Fulfill (R2F) Value Stream:

  • Helps your IT organization transition to a service broker model
  • Presents a single catalog with items from multiple supplier 
  • Efficiently manages subscriptions and total cost of service
  • Manages and measures fulfillments across multiple suppliers

The Detect to Correct (D2C) Value Stream:

  • Brings together IT service operations to enhance results and efficiency
  • Enables end-to-end visibility using a shared configuration model
  • Identifies issues before they affect users
  • Reduces the mean time to repair

4 Target Audience

The target audience for the standard consists of:

  • IT executives
  • IT process analysts
  • Architects tasked with “business of IT” questions
  • Development and operations managers
  • Consultants and trainers active in the IT industry

5 Scope

The Open Group IT4IT standard is focused on defining, sourcing, consuming, and managing IT services by looking holistically at the entire IT Value Chain. While existing frameworks and standards have placed their main emphasis on process, this standard is process-agnostic, focused instead on the data needed to manage a service through its lifecycle. It then describes the functional components (software) that are required to produce and consume the data. Once integrated together, a system of record fabric for IT management is created that ensures full visibility and traceability of the service from cradle to grave.

IT4IT is neutral with respect to development and delivery models. It is intended to support Agile as well as waterfall approaches, and lean Kanban process approaches as well as fully elaborated IT service management process models.

The IT4IT Reference Architecture relates to TOGAF®, ArchiMate®, and ITIL® as shown below:

By The Open Group6 Relevant Website

For further details on the IT4IT Reference Architecture standard, visit www.opengroup.org/IT4IT.

Leave a comment

Filed under IT4IT, Standards, Value Chain

Strategic Planning – Ideas to Delivery

By Martin Owen, CEO, Corso

Most organizations operate at a fast pace of change. Businesses are constantly evaluating market demands and enacting change to drive growth and develop a competitive edge.

These market demands come from a broad number of sources, and include economic changes, market trends, regulations, technology improvements and resource management. Knowing where the demands originated, whether they are important and if they are worth acting on can be difficult.

We look at how innovation, Enterprise Architecture and successful project delivery needs to be intertwined and traceable.

In the past, managing ideation to the delivery of innovation has not been done, or has been attempted in organizational silos, leading to disconnections. This in turn results in change not being implemented properly or a focus on the wrong type of change.

How Does an Organization Successfully Embrace Change?

Many companies start with campaigns and ideation. They run challenges and solicit ideas from within and outside of their walls. Ideas are then prioritized and evaluated. Sometimes prototypes are built and tested, but what happens next?

Many organizations turn to the blueprints or roadmaps generated by their enterprise architectures, IT architectures and or business process architectures for answers. They evaluate how a new idea and its supporting technology, such as SOA or enterprise-resource planning (ERP), fits into the broader architecture. They manage their technology portfolio by looking at their IT infrastructure needs.

Organizations often form program management boards to evaluate ideas, initiatives and their costs. In reality, these evaluations are based on lightweight business cases without the broader context. organizations don’t have a comprehensive understanding of what systems, processes and resources they have, what they are being used for, and how much they cost and the effects of regulations. Projects are delivered and viewed on a project-by-project basis without regard to the bigger picture. Enterprise, technology and process-related decisions are made within the flux of change and without access to the real knowledge contained within the organisation or in the market place. IT is often in the hot seat of this type of decision-making.

Challenges of IT Planning

IT planning takes place in reaction to and anticipation of these market demands and initiatives. There may be a need for a new CRM or accounting system, or new application for manufacturing or product development. While IT planning should be part of a broader enterprise architecture or market analysis, IT involvement in technology investments are often done close to the end of the strategic planning process and without proper access to enterprise or market data.

The following questions illustrate the competing demands found within the typical IT environment:

How can we manage the prioritization of business, architectural-and project-driven initiatives?

Stakeholders place a large number of both tactical and strategic requirements on IT. IT is required to offer different technology investment options, but is often constrained by a competition for resources.

How do we balance enterprise architecture’s role with IT portfolio management?

An enterprise architect provides a high-level view of the risks and benefits of a project and the alignment to future goals. It can illustrate the project complexities and the impact of change. Future state architectures and transition plans can be used to define investment portfolio content. At the same time, portfolio management provides a detailed perspective of development and implementation. Balancing these often-competing viewpoints can be tricky.

How well are application lifecycles being managed?

Application management requires a product/service/asset view over time. Well-managed application lifecycles demand a process of continuous releases, especially when time to market is key. The higher level view required by portfolio management provides a broader perspective of how all assets work together. Balancing application lifecycle demands against a broader portfolio framework can present an inherent conflict about priorities and a struggle for resources.

How do we manage the numerous and often conflicting governance requirements across the delivery process?

As many organizations move to small-team agile development, coordinating the various application development projects becomes more difficult. Managing the development process using waterfall methods can shorten schedules but can also increase the chance of errors and a disconnect with broader portfolio and enterprise goals.

How do we address different lifecycles and tribes in the organization?

Lifecycles such as innovation management, enterprise architecture, business process management and solution delivery are all necessary but are not harmonised across the enterprise. The connection among these lifecycles is important to the effective delivery of initiatives and understanding the impact of change.

The enterprise view, down through innovation management, portfolio management, application lifecycle management and agile development represent competing IT viewpoints that can come together using an ideas to delivery framework.

Agile Development and DevOps

A key component of the drive from ideas to delivery is how strategic planning and the delivery of software are related or more directly the relevance of Agile Enterprise Architecture to DevOps.

DevOps is a term that has been around since the end of the last decade, originating from the Agile development movement and is a fusion of “development” and “operations”. In more practical terms it integrates developers and operations teams in order to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.

The drivers behind the approach are the competing needs to incorporate new products into production whilst maintaining 99.9% uptime to customers in an agile manner.

To understand further the increase in complexity we need to look at how new features and functions need to be applied to our delivery of software. The world of mobile apps, middleware and cloud deployment has reduced release cycles to weeks not months with an emphasis on delivering incremental change. Previously a business release would be every few months with a series of modules and hopefully still relevant to the business goals.

The shorter continuous delivery lifecycle will help organizations:

  • Achieve shorter releases by incremental delivery and delivering faster innovation.
  • Be more responsive to business needs by improved collaboration, better quality and more frequent releases.
  • Manage the number of applications impacted by business release by allowing local variants for a global business and continuous delivery within releases.

The Devops approach achieves this by providing an environment that:

  • Will minimize software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed.
  • Has the notion of projects replaced by release trains which minimizes batch waiting time to reduce lead times and waste.
  • Has a shift from central planning to decentralized execution with a pull philosophy thus minimizing batch transaction cost to improve efficiency.
  • Makes DevOps economically feasible through test virtualization, build automation, and automated release management as we prioritize and sequence batches to maximize business value and select the right batches, sequence them in the right order, guide the implementation, track execution and make planning adjustments to maximize business value.

By Martin Owen, CEO, CorsoFigure 1: DevOps lifecycle

Thus far we have only looked at the delivery aspects, so how does this approach integrate with an enterprise architecture view?

To understand this we need to look more closely at the strategic Planning Lifecycle. Figure 2 shows how the strategic planning lifecycle supports an ‘ideas to delivery’ framework.

By Martin Owen, CEO, Corso

Figure 2: The strategic planning lifecycle

You can see here, the high level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. The enterprise architecture provides the model to govern the delivery of projects in line with these goals.

However we must ensure that any model that is built must be just enough EA to provide the right level of analysis and this has been discussed in previous sections of this book regarding the use of Kanban to drive change. The Agile EA model is then one that can both provide enough analysis to plan which projects should be undertaken and then to ensure full architectural governance over the delivery. The last part of this is achieved by connecting to the tools used in the Agile space.

By Martin Owen, CEO, Corso

Figure 3: Detailed view of the strategic planning lifecycle

There are a number of tools that can be used within DevOps. One example is the IBM toolset, which uses open standards to link to other products within the overall lifecycle. This approach integrates the Agile enterprise architecture process with the Agile Development process and connects project delivery with effective governance of the project lifecycle and ensures that even if the software delivery process is agile the link to goals and associated business needs are met.

To achieve this goal a number of internal processes must interoperate and this is a significant challenge, but one that can be met by building an internal center of excellence and finding a solution by starting small and building a working environment.

The Strategic Planning Lifecycle Summary

The organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? The organization can create a series of campaigns or challenges to solicit new ideas and requirements for its vision and strategy.

The ideas and requirements are rationalized into a value proposition that can be examined in more detail.

The company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions and new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed.

An enterprise architecture is a living thing with a lifecycle of its own. Figure 3 shows the ongoing EA processes. With the strategy and transition plan in place, EA execution begins. The transition plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and entered into, or continue to the Devops stage. As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization.

If we’re not doing things the way we said we wanted them done, then we must ask if our target architectures are still correct. This helps keep the EA current and useful.

Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. Then the transition plan is examined to see if it is still moving us in the right direction. If not, it is updated.

Figure 3, separates the organization’s strategy and vision, the enterprise architecture lifecycle components and the solution development & delivery. Some argue that the strategy and vision are part of the EA while others argue against this. Both views are valid since they simply depend on how you look at the process. If the CEO’s office is responsible for the vision and strategy and the reporting chain as responsible for its execution, then the separation of it from the EA makes sense. In practice, the top part of the reporting chain participates in the vision and strategy exercise and is encouraged to “own” it, at least from an execution perspective. In that case, it might be fair to consider it part of the EA. Or you can say it drives the EA. The categorization isn’t as important as understanding how the vision and strategy interacts with the EA, or the rest of the EA, however you see it.

Note that the overall goal here is to have traceability from our ideas and initiatives, all the way through to strategic delivery. This comes with clear feedback from delivery assets to the ideas and requirements that they were initiated from.

By Martin Owen, CEO, CorsoMartin Owen, CEO, Corso, has held executive and senior management and technical positions in IBM, Telelogic and Popkin. He has been instrumental in driving forward the product management of enterprise architecture, portfolio management and asset management tooling.

Martin is also active with industry standards bodies and was the driver behind the first business process-modelling notation (BPMN) standard.

Martin has led the ArchiMate® and UML mapping initiatives at The Open Group and is part of the capability based planning standards team.

Martin is responsible for strategy, products and direction at Corso.

1 Comment

Filed under Uncategorized

The Open Group ArchiMate® Model Exchange File Format and Archi 3.3

By Phil Beauvoir

Some of you might have noticed that Archi 3.3 has been released. This latest version of Archi includes a new plug-in which supports The Open Group ArchiMate Model Exchange File Format standard. This represents the fruits of some years and months’ labour! I’ve been collaborating with The Open Group, and representatives from associated parties and tool vendors, for some time now to produce a file format that can be used to exchange single ArchiMate models between conforming toolsets. Finally, version 1.0 of the standard has been released!

The file format uses XML, which is backed by a validating XSD Schema. Why is this? Wouldn’t XMI be better? Well, yes it would if we had a MOF representation of the ArchiMate standard. Currently, one doesn’t exist. Also, it’s very hard to agree exactly what should be formally represented in a persistence format, as against what can be usefully represented and exchanged using a persistence format. For example, ArchiMate symbols use colour to denote the different layers, and custom colour schemes can be employed to convey meaning. Clearly, this is not something that can be enforced in a specification. Probably the only things that can be enforced are the ArchiMate concepts and relations themselves. Views, viewpoints, and visual arrangements of those concepts and relations are, arguably, optional. A valid ArchiMate model could simply consist of a set of concepts and relations. However, this is probably not very useful in the real world, and so the exchange format seeks to provide a file format for describing and exchanging the most used aspects of ArchiMate models, optional aspects as well as mandatory aspects.

So, simply put, the aim of The Open Group ArchiMate Model Exchange File Format is to provide a pragmatic and useful mechanism for exchanging ArchiMate models and visual representations between compliant toolsets. It does not seek to create a definitive representation of an ArchiMate model. For that to happen, I believe many things would have to be formally declared in the ArchiMate specification. For this reason, many of the components in the exchange format are optional. For example, the ArchiMate 2.1 specification describes the use of attributes as a means to extend the language and provide additional properties to the concepts and relations. The specification does not rigidly mandate their use. However, many toolsets do support and encourage the use of attributes to create model profiles, for example. To support this, the exchange format provides a properties mechanism, consisting of typed key/value pairs. This allows implementers to (optionally) represent additional information for all of the concepts, relations and views.

Even though I have emphasised that the main use for the exchange format is exchange (the name is a bit of a giveaway here ;-)), another advantage of using XML/XSD for the file format is that it is possible to use XSLT to transform the XML ArchiMate model instances into HTML documents, reports, as input for a database, and so on. I would say that the potential for exploiting ArchiMate data in this way is huge.

The exchange format could also help with learning the ArchiMate language and Enterprise Architecture – imagine a repository of ArchiMate models (tagged with Dublin Core metadata to facilitate search and description) that could be used as a resource pool of model patterns and examples for those new to the language. One thing that I personally would like to see is an extensive pool of example models and model snippets as examples of good modelling practice. And using the exchange format, these models and snippets can be loaded into any supporting toolset.

Here are my five “winning features” for the ArchiMate exchange file format:

  • Transparent
  • Simple
  • Well understood format
  • Pragmatic
  • Open

I’m sure that The Open Group ArchiMate Model Exchange File Format will contribute to, and encourage the use of the ArchiMate modelling language, and perhaps reassure users that their valuable data is not locked into any one vendor’s proprietary tool format. I personally think that this is a great initiative and that we have achieved a great result. Of course, nothing is perfect and the exchange format is still at version 1.0, so user feedback is welcome. With greater uptake the format can be improved, and we may see it being exploited in ways that we have not yet thought of!

(For more information about the exchange format, see here.)

About The Open Group ArchiMate® Model Exchange File Format:

The Open Group ArchiMate® Model Exchange File Format Standard defines a file format that can be used to exchange data between systems that wish to import, and export ArchiMate models. ArchiMate Exchange Files enable exporting content from one ArchiMate modelling tool or repository and importing it into another while retaining information describing the model in the file and how it is structured, such as a list of model elements and relationships. The standard focuses on the packaging and transport of ArchiMate models.

The standard is available for free download from:


An online resource site is available at http://www.opengroup.org/xsd/archimate.

By Phil BeauvoirPhil Beauvoir has been developing, writing, and speaking about software tools and development for over 25 years. He was Senior Researcher and Developer at Bangor University, and, later, the Institute for Educational Cybernetics at Bolton University, both in the UK. During this time he co-developed a peer-to-peer learning management and groupware system, a suite of software tools for authoring and delivery of standards-compliant learning objects and meta-data, and tooling to create IMS Learning Design compliant units of learning.  In 2010, working with the Institute for Educational Cybernetics, Phil created the open source ArchiMate Modelling Tool, Archi. Since 2013 he has been curating the development of Archi independently. Phil holds a degree in Medieval English and Anglo-Saxon Literature.

Leave a comment

Filed under ArchiMate®, Standards, The Open Group

Update on The Open Group France: A Conversation with Eric Boulay

By The Open Group

Following this spring’s European Summit, we reached out to Eric Boulay, our French partner, to catch up on the latest goings on at The Open Group France. Boulay, who is also the CEO of our French affiliate, Arismore, provided us an update on affiliate growth and also discussed the architectural issues currently facing French companies.


As Eric points out in the interview below, digital transformation is one of the largest trends French companies are grappling with. To provide some guidance, The Open Group France has recently published a new whitepaper entitled “Key Issues and Skills in Digital Transformation.” In addition, the organization uses a new publication, “TOGAF En Action” to organize meetings and share TOGAF® case studies. The TOGAF 9.1 Pocket Guide has also recently been translated into French, and a French TOGAF app is now available for iPhone users with an Android version in the works.

One new member, Adservio, has joined The Open Group France in the past quarter, and three memberships were recently renewed. The Open Group France will host an Architecture Practitioners Conference in Paris on June 17th.


What are some of the latest goings on with The Open Group France?

France is accelerating in digital transformation so now is a good time to speed up architectural discipline. Training is doing well, and consistency and service in TOGAF®, an Open Group standard, and Enterprise Architecture are doing well because there is a move toward digital transformation. In the France architecture forum, we have meetings every six weeks to share activities and case studies. We are currently raising awareness for The Open Group IT4IT™ Forum. It’s not well-known today in France. It’s just starting up and a brand new subject.

What technology trends are Enterprise Architects in Europe grappling with today?

Definitely there is more interest in closing the gap between strategy, business and information systems. There are two topics – one is what we used to call enterprise IT architecture. IT guys are working to be more and more effective in managing IT assets—this has been the same story for a while. But what is emerging right now is—and this is due to digital transformation—there is a strong need to close the gap between enterprise strategy and information systems. This means that we are working, for example, with ArchiMate® to better understand business motivations and to go from business motivations to a roadmap to build next generation information systems. So this is a new topic because now we can say that Enterprise Architecture is no longer just an IT topic, it’s now an enterprise topic. Enterprise Architects are more and more in the right position to work both on the business and IT sides. This is a hot topic, and France is participating in the Information Architecture Work Group to propose new guidance and prescriptions. Also there is some work on the table with TOGAF to better close the gap between strategy and IT. This is exactly what we have to do better in the The Open Group Architecture Forum, and we’re working on it.

What are some of the things that can be done to start closing that gap?

First is to speak the business language. What we used to do is really to work close with the business guys. We have to use, for example, ArchiMate language but not talk about ArchiMate languages.

For example, there was an international account we had in Europe. We flew to different countries to talk to the business lines and the topic was shared services, like SAP or ERP, and what they could share with subsidiaries in other countries. We were talking about the local business, and by the end of the day we were using ArchiMate and the Archie tool to review and wrap up the meeting. These documents and drawings were very useful to explicitly figure out what exactly this business line needed. Because we had this very formal view of what they needed that was very valuable to be able to compare it with other business lines, and then we were in the position to help them set up the shared services in an international standard view. We definitely used ArchiMate tools, language and the Archie tools. We were talking about strategy and motivation and at the end of the day we shared the ArchiMate view of what they could share, and three months later they are very happy with the deliverables because we were able to provide view across different business units and different countries and we are ready to implement shared services with ERP in different countries and business lines. The method, the language, TOGAF, ArchiMate language—and also Enterprise Architect soft skills—all of these were key differentiators in being able to achieve this job.

What other things are you seeing Enterprise Architects grappling with in Europe?

Obviously Big Data and data analysis is really hyped today. Like the U.S., the first problem is that Europe needs resources and skills to work on these new topics. We are very interested in these topics, but we have to work to better figure out what kind of architecture and reference architectures we can use for that. The Open Platform 3.0™ Forum trends and reference architecture are key to fostering the maturity of the domain.

The second topic is IT4IT—behind IT4IT there is a financial issue for IT people to always deliver more value and save money. If I understand where we are going with IT4IT, we are trying to develop a reference architecture which helps companies to better deliver service with an efficient cost rationale. This is why we are taking part in IT4IT. When we promote IT4IT at the next French event in June we will talk about IT4IT because it’s an opportunity to review the IT service portfolio and the way to deliver it in an effective way.

It’s not so easy with us with security because today it’s a local issue. What I mean by local issue is, in every country in Europe and especially in France, cybersecurity and data privacy are on the government agenda. It’s a sovereignty issue, and they are cautious about local solutions. France, and especially the government, is working on that. There are works at the European level to set up policies for European data privacy and for cyber criminality. To be honest, Europe is not 100 percent confident with security issues if we’re talking about Facebook and Google. It’s not easy to propose an international framework to fix security issues. For example, Arismore is working with EA and security. EA is easy to promote – most of the major French companies are aware of TOGAF and are using EA and TOGAF even more, but not security because we have ISO 27001 and people are not very confident with U.S.-based security solutions.


Comments Off on Update on The Open Group France: A Conversation with Eric Boulay

Filed under ArchiMate®, EA, Enterprise Architecture, IT4IT, The Open Group, The Open Group France, TOGAF®

Why We Like ArchiMate®

What Are Your Thoughts?

By Allen Brown, President & CEO of The Open Group

This year marks the 30th anniversary of my class graduation from the London Business School MBA program. It was 3 years of working full-time for Unilever and studying every minute possible, and tackling what seemed to be impossible case studies on every subject that you would have to deal with when managing a business.

One of the many core subjects was “Operations Management”: organizing people, materials and technology into an efficient unit. The first thing we were taught was that there are no rules, only pressures and opportunities. The next thing was that there are no boundaries to what can have an impact on the subject: from macro issues of structure and infrastructure to micro issues of marketing, capabilities, location, motivation and much more. It required a lot of analysis and a lot of thinking around realistic solutions of how to change the “now” state.

To support this, one of the techniques we were taught was modeling. There was one case study that I recall was about a small company of less than 150 personnel engaged in the manufacture and development of fast sea-based transport. As part of the analysis I modeled the physical flow system which covered all aspects of the operation from sales to customer feedback and from design to shipment – all in pencil and all on one page. An extract is shown here.

By Allen Brown, President & CEO, The Open Group

I don’t know if it’s just me but that looks very similar to some ArchiMate® models I have seen. OK there is not a specific box or symbol for the actors and their roles or for identifying processes but it is clear, who is responsible what, the function or process that they perform and the information or instructions they pass to or receive from their colleagues.

So it should not be surprising that I would like ArchiMate®, even before it became a standard of The Open Group and by the same token many people holding senior positions in organizations today, have also been through MBA programs in the past, or some form of executive training and as such would be familiar with the modeling that I and my classmates were taught and would therefore easily understand ArchiMate models.

Since graduating, I have used modeling on many occasions to assist with understanding of complex processes and to identify where problems, bottlenecks, delays and unnecessary costs arise. Almost everyone, wherever they are in the organization has not only understood them but also been able to improve them, with the possible exception of software developers, who still needed UML and BPMN.

An ArchiMate Focus Group

A few months ago I got together with some users of ArchiMate to try to understand its appeal to others. Some were in large financial services businesses, others were in healthcare and others were in consulting and training organizations.

The first challenge, of course, is that different people, in different situations, with different roles in different organizations in different countries and continents will always see things differently. In The Open Group there are more than 300,000 people from over 230 different countries; nearly one third of those people identify themselves as “architects”; and of those “architects” there are more than 3,400 job titles that contain the word architect. There are also more than 3,500 people who identify themselves as CEO, nearly 5,500 CIO’s etc.

So one size definitely will not fit all and neither will a single statement produced by a small number of people sat in a room for a day.

So what we did was to focus mostly on a senior executive in a major financial services company in the United States whose team is responsible for maintaining the business capability map for the company. After that we tested the results with others in the financial services industry, a representative from the healthcare industry and with an experienced consultant and trainer.

Ground Rules for Feedback

Now, what I would like to get feedback on is your views, which is the reason for writing this blog. As always there are some ground rules for feedback:

  • Please focus on the constructive
  • Please identify the target audience for the messages as closely as you can: e.g. job title / type; industry; geographic location etc

With those thoughts in mind, let me now share what we have so far.

The Value of ArchiMate

For the person that we initially focused on, he felt that The Open Group ArchiMate® Standard is the standard visual language for communicating and managing the impact of change. The reasons behind this are that it bridges between strategy, solutions and execution and it enables explicit communication.

The value of bridging between strategy, solutions and execution is recognized because it:

  • Accelerates value delivery
  • Integrates between disciplines
  • Describes strategic capabilities, milestones and outcomes

Enabling explicit communication is realized because it:

  • Improves understanding at all levels of the organization
  • Enables a short time to benefit
  • Is supported by leading tool vendors

A supporting comment from him was that ArchiMate enables different delivery approaches (e.g. waterfall, agile). From a modeling point of view the diagrams are still the same, but the iteration cycles and utilization of them become very different in the agile method. Interesting thought.

This is obviously different from why I like ArchiMate but also has some similarities (e.g. easily understood by anyone) and it is a perfect example of why we need to recognize the differences and similarities when communicating with different people.

So when we asked others in the financial services whether they agreed or not and to tell us why they like ArchiMate, they all provided great feedback and suggested improvements. They identified two groups

  • The CEO, CIO, Business Analyst and Business Architect; and
  • Areas of business support and IT and Solution Architects and System Analysts.

All agreed that The Open Group ArchiMate® Standard is the standard visual language. Where they varied was in the next line. For the CEO, CIO, Business Analyst and Business Architect target audience the value of ArchiMate, was realized because:

  • It is for modeling the enterprise and managing its change
  • It can support strategic alignment and support impact analysis

Instead of “enabling explicit communication” others preferred the simpler, “clarifies complex systems” but the sub-bullets remained the same. One supporting statement was, “I can show a diagram that most people can understand even without technical knowledge”. Another statement, this time in support of the bridging capability was, “It helps me in unifying the languages of business and IT”.

The value of strategic alignment support was realized through ArchiMate because it:

  • Allows an integrated view
  • Depicts links between drivers and the specific requirements that address them
  • Links between motivation and business models

Its support of impact analysis and decision taking recognizes the bridging capability:

  • Integrates between disciplines: links between cause and effect
  • Describes and allows to identify, strategic capabilities
  • Bridges between strategy, solutions and execution

When the target audience changed to areas of business support and IT or to Solution Architects and System Analysts, the next line became:

  • It is for communicating and managing change that leverages TOGAF® standard usage
  • It can support the development of conceptual representations for the applications and IT platforms and their alignment with business goals

For these audiences the value was still in the ability to clarify complex systems and to bridge between strategy, solutions and execution but the sub-bullets changed significantly:

  • Clarifies complex systems
    • Improves understanding at all levels of the organization
    • Allows integration between domains
    • Provides a standard way to represent inputs and outputs between domains
    • Supports having a standard model repository to create views
  • Bridges between strategy, solutions and execution
    • Allows views segmentation efficiently
    • Allow a consolidated organizational landscape definition business aligned
    • Supports solutions design definition

Unlike my business school models, ArchiMate models are also understandable to software developers.

The feedback from the healthcare organization was strikingly similar. To give an example format for feedback, I will represent it in a way that would be very helpful if you could use for your comments.

Country: USA

Industry: Healthcare

Target Audience: VP of IT

Positioning statement:

The Open Group ArchiMate® Standard is the standard visual language for communicating and managing change and making the enterprise architecture practice more effective.

It achieves this because it:

  • Clarifies complex systems
    • Improves understanding at all levels of the organization
    • Short time to benefit
    • Supported by leading tool vendors
    • Supports a more effective EA delivery
  • Bridges between strategy, solutions and execution
    • Accelerates value delivery
    • Integrates between disciplines
    • Describes strategic capabilities, milestones and outcomes

Feedback from an experienced consultant and trainer was:

Country / Region: Latin America


Target Audience: Director of Business Architecture, Chief EA, Application Architects

Positioning statement:

The Open Group ArchiMate® Standard is the standard visual language for modeling the organization, leveraging communication with stakeholders and managing change

It achieves this because it:

  • Clarifies complex systems and leverage change
    • Improves understanding at all levels of the organization
    • Supported by leading tool vendors
    • Support change impact analysis into the organization and it is a helping tool portfolio management and analysis
    • Supports complex system structures presentation to different stakeholders using a simplified notation
  • Bridges between strategy, solutions and execution
    • Accelerates value delivery
    • Integrates between disciplines
    • Describes strategic capabilities, milestones and outcomes
    • Allow a consolidated organizational landscape definition

Your Feedback

All of this gives us some insight into why a few of us like ArchiMate. I would like to know what you like about ArchiMate or how you talk about it to your colleagues and acquaintances.

So please do not hesitate to let me know. Do you agree with the statements that have been made so far? What improvements would you suggest? How do they resonate in your country, your industry, your organization? What different audiences should be addressed and what messages should we use for them?

Please email your feedback to ArchiMateFeedback@opengroup.org.

By The Open GroupAllen Brown is President and CEO of The Open Group – a global consortium that enables the achievement of business objectives through IT standards.  He is also President of the Association of Enterprise Architects (AEA).

Allen was appointed President & CEO in 1998.  Prior to joining The Open Group, he held a range of senior financial and general management roles both within his own consulting firm, which he founded in 1987, and other multi-national organizations.

Allen is TOGAF® 9 certified, an MBA alumnus of the London Business School and a Fellow of the Association of Chartered Certified Accountants.

1 Comment

Filed under Allen Brown, ArchiMate®, Business Architecture, Enterprise Transformation, The Open Group