11 August, 2014
10 September, 2013
- A business process, application, or set of applications that can be enabled by the architecture
- The business and technology environment
- The people and computing components (called "actors") who execute the scenario
- The desired outcome of proper execution"
A Quality Attribute Workshop (QAW) is a systematic approach to elicit the needed requirements. This will ensure that all quality attributes are included in the final design. To This end it:
- is a facilitated method that engages system stakeholders early in the life cycle to discover the driving quality attributes of a software-intensive system
- provides a way to identify important quality attributes and clarify system requirements before the software architecture has been created (Implementation Governance)
- is based on the qualities and the non-functional requirements that may be captured in the Architecture Vision document, the team will identify and elaborate specific quality attribute scenarios and document them
- produces a documentation that includes most of the quality attributes specified by the stakeholders
- System Architecture: the fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviours
- Software Architecture: the structure or structures of the system, which comprise software elements, the externally visible properties of those elements and the relationships among them
It is also a purpose of identifying scenarios from the point of view of a diverse group of stakeholders which can then be used by the system engineers to analyse the system’s architecture and identify concerns. QAW is mainly addressing non-functional requirements and there is still needs to understand the problems we try to solve, gather functional requirements like in Business Scenarios.
Quality Attribute Workshops ensure that quality attribute scenarios are identified, prioritized, and refined before the software architecture is completed. Individual requirements are viewed in a forum in relation to one another in the context of the overall problem. Architecture is based on complete set of requirements that add up to a whole problem description.
Technique requires involvement - at an early stage in architecture project
- Business stakeholders (end users)
- Systems stakeholders (installers, administrators, DBAs; network, training, acquirers, system and software engineers, etc.)
- Other stakeholders (such as Operations amongst others)
- Increased stakeholder communication, an informed basis for architectural decisions
- Improved architectural documentation, and support for analysis and testing throughout the life of the system
- A list of architectural drivers
- Raw scenarios
- A prioritized list of raw scenarios
- Refined scenarios
Below are the steps of the QAW.
Business and/or mission drivers for the system (goals and drivers), plan, strategies, high-level functional requirements, constraints, artifacts and quality attribute requirements should be presented to the stakeholders. Using Business Scenario in conjunction with QAWs can be an appropriate approach.
A QAW lends itself to the capture of many architecturally relevant materials:
- Software architectural documentation is a collection of view packets plus any documentation that applies to more than one view
- Each view packet contains a primary presentation, a catalogue of the view’s elements (including element behaviour), use case diagrams, sequence diagram, context diagrams, collaboration diagram, a variability guide, architecture background (rationale, analysis results, and assumptions about the environment), and other information including mapping to requirements
The outputs from the QAW can be summarised as:
- A list of architectural drivers
- Raw scenarios
- A prioritized list of raw scenarios
- Refined scenarios
Software architectures must be designed so that their quality attributes are met.
The QAWs technique can be utilised as a complementary approach to gather all sort of requirements including those from Software Architectures when appropriate.
08 May, 2013
Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0
One of the responsibilities of an Enterprise Architect is to provide complete traceability from requirements analysis and design artefacts, through to implementation and deployment.
Along the years, I have found out that the term traceability is not always really considered in the same way by different Enterprise Architects.
Let’s start with a definition of traceability. Traceable is an adjective; capable of being traced. Trying to find a definition even from a dictionary is a challenge and the most relevant one I found on Wikipedia which may be used as a reference could be “The formal definition of traceability is the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable.”
In Enterprise Architecture, traceability may mean different things to different people.
Some people refer to
· Enterprise traceability which proves alignment to business goals
· End-to-end traceability to business requirements and processes
· A traceability matrix, the mapping of systems back to capabilities or of system functions back to operational activities
· Requirements traceability which assists in quality solutions that meets the business needs
· Traceability between requirements and TOGAF artifacts
· Traceability across artifacts
· Traceability of services to business processes and architecture
· Traceability from application to business function to data entity
· Traceability between a technical component and a business goal
· Traceability of security-related architecture decisions
· Traceability of IT costs
· Traceability to tests scripts
· Traceability between artifacts from business and IT strategy to solution development and delivery
· Traceability from the initial design phase through to deployment
· And probably more
The TOGAF 9.1 specification rarely refers to traceability and the only sections where the concept is used are in the various architecture domains where we should document a requirements traceability report or traceability from application to business function to data entity.
The most relevant section is probably where in the classes of architecture engagement it says:
“Using the traceability between IT and business inherent in enterprise architecture, it is possible to evaluate the IT portfolio against operational performance data and business needs (e.g., cost, functionality, availability, responsiveness) to determine areas where misalignment is occurring and change needs to take place.”
And how do we define and document Traceability from an end user or stakeholder perspective? The best approach would probably to use a tool which would render a view like in this diagram:
In this diagram, we show the relationships between the components from the four architecture domains. Changing one of the components would allow doing an impact analysis.
Components may have different meanings as illustrated in the next diagram:
Using the TOGAF 9.1 framework, we would use concepts of the Metamodel. The core metamodel entities show the purpose of each entity and the key relationships that support architectural traceability as stipulated in the section 34.2.1 Core Content Metamodel Concepts.
So now, how do we build that traceability? This is going to happen along the various ADM cycles that an enterprise will support. It is going to be quite a long process depending on the complexity, the size and the various locations where the business operates.
There may be five different ways to build that traceability:
· Manually using an office product
· With an enterprise architecture tool not linked to the TOGAF 9.1 framework
· With an enterprise architecture tool using the TOGAF 9.1 artifacts
· With an enterprise architecture tool using ArchiMate 2.0
· Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository
1. Manually using an office product
You will probably document your architecture with the use of word processing, spread sheets and diagramming tools and store these documents in a file structure on a file server, ideally using some form of content management system.
Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system or an enterprise. The links between these deliverables soon becomes non manageable and in the long term impact analysis of any change will become quite impossible. Information will be hard to find and to trace from requirements all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spread sheets and use cases and business goals are contained in separate documents. Other issues such as maintenance and consistency would have to be considered.
2. With an enterprise architecture tool not linked to the TOGAF 9.1 framework
Many enterprise architecture tools or suites provide different techniques to support traceability but do not really describe how things work and focus mainly on describing requirements traceability. In the following example, we use a traceability matrix between user requirements and functional specifications, use cases, components, software artifacts, test cases, business processes, design specifications and more.
Mapping the requirements to use cases and other information can be very labor-intensive.
Some tools also allow for the creation of relationships between the various layers using grids or allowing the user to create the relationships by dragging lines between elements.
Below is an example of what traceability would look like in an enterprise architecture tool after some time. That enterprise architecture ensures appropriate traceability from business architecture to the other allied architectures.
3. With an enterprise architecture tool using the TOGAF 9.1 artifacts
The TOGAF 9.1 core metamodel provides a minimum set of architectural content to support traceability across artifacts. Usually we use catalogs, matrices and diagrams to build traceability independently of dragging lines between elements (except possibly for the diagrams). Using catalogs and matrices are activities which may be assigned to various stakeholders in the organisation and theoretically can sometimes hide the complexity associated with an enterprise architecture tool.
Using artifacts creates traceability. As an example coming from the specification; “A Business Footprint diagram provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified”. There are other artifacts which also describe other traceability: Data Migration Diagram and Networked Computing/Hardware Diagram.
4. With an enterprise architecture tool using ArchiMate 2.0
Another possibility could be the use of the ArchiMate standard from The Open Group. Some of the that traceability could also be achievable in some way using BPMN and UML for specific domains such as process details in Business Architecture or building the bridge between Enterprise Architecture and Software architecture.
With ArchiMate 2.0 we can define the end to end traceability and produce several viewpoints such as the Layered Viewpoint which shows several layers and aspects of an enterprise architecture in a single diagram. Elements are modelled in five different layers when displaying the enterprise architecture; these are then linked with each other using relationships. We differentiate between the following layers and extensions:
· Business layer
· Application layer
· Technology layer
· Motivation extension
· Implementation and migration extension
The example from the specification below documents the various architecture layers.
As you will notice, this ArchiMate 2.0 viewpoint looks quite similar to the TOGAF 9.1 Business Footprint Diagram which provides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.
Another example could be the description of the traceability among business goals, technical capabilities, business benefits and metrics. The key point about the motivation extension is to work with the requirement object.
Using the motivation viewpoint from the specification as a reference (motivation extension), you could define business benefits / expectations within the business goal object, and then define sub-goals as KPIs to measure the benefits of the plan and list all of the identified requirements of the project / program. Finally, you could link these requirements with either application or infrastructure service object representing software or technical capabilities. (Partial example below).
One of the common questions I have recently received from various enterprise architects is “Now that I know TOGAF and ArchiMate… how should I model my enterprise? Should I use the TOGAF 9.1 artifacts to create that traceability? Should I use ArchiMate 2.0? Should I use both? Should I forget the artifacts...”. These are good questions and I’m afraid that there is not a single answer.
What I know is that if I select an enterprise architecture tool supporting both TOGAF 9.1 and ArchiMate 2.0, I would like to be able to be able to have a full synchronization. If I model a few ArchiMate models I would like my TOGAF 9.1 artifacts to be created at the same time (catalogs and matrices) and if I create artifacts from the taxonomy, I would like my ArchiMate models also to be created.
Unfortunately I do not know the current level of tools maturity and whether tools vendors provide that synchronization. This would obviously require some investigation and should be one of the key criteria if you were currently looking for a product supporting both standards.
5. Replicating the content of an Enterprise Repository such as a CMDB in an Architecture repository
This other possibility requires that you have an up to date Configuration Management Database and that you developed an interface with your Architecture Repository, your enterprise architecture tool. If you are able to replicate the relationships between the infrastructure components and applications (CIs) into your enterprise architecture tool that would partially create your traceability.
If I summarise the various choices to build that enterprise architecture traceability, I potentially have three main possibilities:
Achieving traceability within an Enterprise Architecture is key because the architecture needs to be understood by all participants and not just by technical people. It helps to incorporate the enterprise architecture efforts into the rest of the organization and it takes it to the board room (or at least the CIO’s office) where it belongs.
· Describe your traceability from your Enterprise Architecture to the system development and project documentation.
· Review that traceability periodically, making sure that it is up to date, and produce analytics out of it.
If a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go Make sure you use the right standard and platform. Finally, communicate and present to your stakeholders the results of your effort.
01 October, 2012
The primary structuring element for SOA applications is a service as distinct from subsystems, systems, or components. A service is an autonomous and discoverable software resource which has a well defined service description.
SOA is based on a fundamental architectural model that defines an interaction model between three primary parties, the service provider, who publishes a service description and provides the implementation for the service, a service consumer, who can either use the uniform resource identifier (URI) for the service description directly or can find the service description in a service registry and bind and invoke the service. The service broker is the third party who provides and maintains the service registry in addition to providing mediation services between providers and consumers.
In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We’re now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Also many enterprise architects are wondering if the mobile business model will drive SOA technologies in a new direction. Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.
To be successful in implementing a SOA initiative, it is highly recommended that a company create a Center of Excellence and the Open Group clearly explains how this can be achieved through the use of TOGAF 9.1. This article is based on the specification and specifically the section (in italics) 188.8.131.52 Partitions and Centers of Excellence with some additional thoughts on sections 184.108.40.206 Principle of Service-Orientation and 220.127.116.11 Governance and Support Strategy.
I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.
The figure below illustrates below a SOA Center of Excellence as part of the Enterprise Architecture team with domain and solution architects as well as developers, QAs and business architects and analysts coming from a delivery organization.
This center of excellence support methodologies, standards, governance processes and manage a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.
Below is then what is written in the TOGAF 9.1 specification.
A successful CoE will have several key attributes:
- A clear definition of the CoE's mission: why it exists, its scope of responsibility, and what the organization and the architecture practice should expect from the CoE.
It may sound obvious, but having a blueprint for SOA is critical. It's very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.
In order to realize the vision of SOA the following topics should be addressed:
· What to build: A Reference Architecture
· How to build: Service-Oriented Modeling Method
· Whether to build: Assessments, roadmaps, and Maturity evaluations
· Guidance on Building: Architectural and Design patterns
· Oversight: Governance
· How to build: Standards and Tools
The Center of Excellence would first have a vision which could be something like:
“ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers”.
Then a mission statement should be communicated across the organization. Below a few examples of mission statements:
“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”
“The mission of the COE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The COE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”
The Center of Excellence would also define a structure and the various interactions with
· the enterprise architecture team
· the project management office
· the business process/planning & strategy group
· the product management group
And create a steering committee or board (which could be associated to an architecture board).
They will provide different types of support:
· Architecture decision support
o Maintain standards, templates and policies surrounding Integration and SOA
o Participate in Integration and SOA design decisions
· Operational support
o Responsible for building and maintaining SOA Infrastructure
o Purchasing registries and products to grow infrastructure
· Development support
o Development of administrative packages and services
o Develop enterprise services based on strategic direction
- Clear goals for the CoE including measurements and Key Performance Indicators (KPIs). It is important to ensure that the measures and KPIs of the CoE do not drive inappropriate selection of SOA as the architecture style.
· Service revenue
· Service vitality
· Ratio between services used and those created
· Mean Time To Service Development or Service change
· Service availability
· Service reuse
· Quality assurance
- The CoE will provide the "litmus test" of a good service.
This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols including: (here a few examples) HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.
Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.
- The CoE will disseminate the skills, experience, and capabilities of the SOA center to the rest of the architecture practice.
- Identify how members of the CoE, and other architecture practitioners, will be rewarded for success.
- Recognition that, at the start, it is unlikely the organization will have the necessary skills to create a fully functional CoE. The necessary skills and experience must be carefully identified, and where they are not present, acquired. A fundamental skill for leading practitioners within the CoE is the ability to mentor other practitioners transferring knowledge, skills, and experience.
· Enterprise Architecture
· Value of SOA
· Governance model for SOA
· Business Process Management and SOA
· Design of SOA solutions
· Technologies and standards
· Business communication
It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.
- Close-out plan for when the CoE has fulfilled its purpose.
The Center of Excellence will then also define a Reference Architecture for the organization.
A Reference Architecture is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.
The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.
A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.
Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.
The Open Group Standard for SOA Reference Architecture (SOA RA) is a good way of considering how to build systems.
The center of Excellence needs also to define the SOA life cycle management which consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.
Simply put, without management and control, there is no SOA only an “Experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.
For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.
These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment. This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.
The “Principle of Service orientation” must exist as defined in 18.104.22.168 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.
Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.
Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.
Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition, are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.
SOA principles should be clearly related back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:
· Put the computing near the data
· Services are technology neutral
· Services are consumable
· Services are autonomous
· Services share a formal contract
· Services are loosely coupled
· Services abstract underlying logic
· Services are reusable
· Services are composable
· Services are stateless
· Services are discoverable
· Location Transparency
Here is a detailed principle example:
· Service invocation
o All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
o The only exception to this principle will be when the service meets all the following criteria:
§ It will be used only within the same application silo
§ There is no potential right now or in the near future for re-use of this service
§ The service has already been right-sized
§ The Review Team has approved the exception
As previously indicated, the Center of Excellence would also have to provide guidelines on SOA processes and related technologies. This may include:
· Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
· Service design (SOAD, specification, Discovery Process, Taxonomy)
· Service provisioning (SPML, contracts, SLA)
· Service implementation development (BPEL, SOAIF)
· Service assembly and integration (JBI, ESB)
· Service testing
· Service deployment (the software on the network)
· Service discovery (UDDI, WSIL, registry)
· Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
· Service consumption (WSDL, BPEL)
· Service execution (WSDM)
· Service versioning (UDDI, WSDL)
· Service Management and monitoring
· Service operation
· Programming, granularity and abstraction
Other activities may be considered by the Center of Excellence such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.
As described in TOGAF 9.1, the Center of Excellence can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.
The Center of Excellence provides expanded opportunities for organizations to leverage and re-use service oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.
01 March, 2012
Generally speaking, IT departments have all sorts of criteria to justify projects and measure their performance. They use measurements and metrics, 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 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 feedbacks from various companies I have worked with.
Without Enterprise Architecture you can probably NOT fully achieve:
- IT alignment with the business goals
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
- Reduced time to market and increased IT responsiveness
- Better access to information across applications and improved interoperability
- Readily available descriptive representations and documentation of the enterprise
- Reduce IT costs by consolidating, standardizing, rationalizing and integrating corporate information systems
Consolidation can happen at various levels for the 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 process helps organizations understand their current Enterprise Maturity level and move forward on the appropriate roadmap.
- More spending on Innovation
- Enabling strategic business goals via better operational excellence
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
- Greater product leadership
- Comply with regulatory requirements
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. Here we would apply the value proposition concept to the Enterprise Architecture initiative as a whole.
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 being inspired by the presentation by Michael van den Dungen and Arjan Visser at the Open Group Conference in Amsterdam 2010 and I’m here adding some Archimate 2.0 concepts.
Firstly 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.” Source Archimate 2.0 Specification), 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 see Operational Excellence and Customer Intimacy as key drivers, 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 meta-models.
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 limited intentionally 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 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. Enterprise Architecture contributes without a doubt 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.