Why Enterprise Architecture for Practitioners (Foundation) training?

October 31st, 2013



Enterprise Architecture for Practitioners (Foundation) training from Architecting the Enterprise is very popular amongst organisations or individuals who are not certification driven and would like to be introduced to the latest TOGAF methods.


The foundation level training product is a brilliant, light weight course to introduce an Enterprise Architecture approach to business and executive teams.  This is a good method to align strategy with business stakeholders when the EA team wishes to establish an Enterprise Architecture practice to their organizations.


To make Enterprise Architecture engagements successful, fostering collaboration is the key. The business stakeholders and Architect team(s) are required to establish a common understanding of the EA strategic plan, to support the business strategy, goals and objectives, whilst eliminating any miscommunication or fragmentation of the requirements along the way.


By attending the Enterprise Architecture for Practitioners (Foundation) course, we will give you an innovative way of setting up the environment to adopt an Enterprise Architecture approach to the organization by using a framework such as TOGAF. Therefore bringing industry tested, open standards into an organisation. This will lead to improved alignment of the business strategy and will drive successful enterprise architecture engagement with all stakeholders.

To read more about this service please see the following link:


If you have any questions about how you can get up to speed with Enterprise Architecture for Practitioners (Foundation) or if you are interested in how you can build Effective Architecture Teams please contact [email protected]


By Linda Yu


Senior Business Development Manager & Asia Manager,

Architecting the Enterprise.

What Creates a Winning Architecture Team?

October 30th, 2013


 by Keith Flanagan


 “The strength of the team is each individual member. 

 The strength of each member is the strength of the team.”

 - Phil Jackson

You have probably already made a subjective assessment of the people that make up your architecture team.  You already have the measure of who is good at what and, who isn’t!

But do you know why some are good and others are not so good at certain things?  And, do you really understand the overall effect each team member has on the rest of the team?


If your team had such a thing as a personality, what would it be?


We’ve been extending our research into architect personality types and have begun to unearth some interesting findings.  We’re also starting to find ways of improving team effectiveness by considering its membership from an individual perspective as well as the overall group dynamic.


You will have your own view of certain organisations.  For example, consider a restaurant that you prefer.  Compare the differences between the restaurant of your choice and one that you prefer not to use.  Your favourite restaurant gives you good service and offers products that are developed to your liking.  Such a combination creates a win/win effect and repeat business for the restaurant.  But if you were greeted by the Head Chef and had your food prepared by the Concierge, then you would probably experience something completely different and not necessarily in a good way!   Clearly, employing the right people in the right positions are key enablers for overall team effectiveness.  You already do this by assigning people to projects to which they are technically suited – but a person’s technical ability should only really be considered as half of their capability.


Building Effective Architecture Teams (or BEAT as we’re now calling it) brings together all of the ingredients that make up the Elevating EA portfolio and serves them up as a banquet for your team and its members.  It’s a new concept and we’re very excited about it.  We hope that you continue choose us as your favourite ‘restaurant.’


And by the way, we’re also announcing new dates and venues for our forthcoming EEA workshops and Webinars.  Visit the table below for details (but you may have to clear away the cutlery first!):



To read more about this service please see the following link:


If you have any questions about how you can get up to speed with Elevating Enterprise Architecture or if you are interested in how you can build Effective Architecture Teams please contact [email protected]


The Open Group Conference London 2013

October 30th, 2013

Last week we were yet again thrilled to be a premium sponsor at The Open Group Conference “Business Transformation in Finance, Government & Healthcare” in London.

As always we really enjoyed meeting up with contacts, old and new and were very proud to continue our support of the conference. In addition, we attended many Forum meetings further contributing to the valuable work within The Open Group.  We also offered attendees the opportunity to “fast track” their professional training in ArchiMate 2.0.

If you attended the Conference, did you see our CEO Judith Jones present her plenary session on the topic of connected Government entitled “One World EA Framework for Government – The Way Forward”? If you missed it you can watch it again via Livestream here.

We are also delighted to announce the winner of our Conference competition, which was to win an Enterprise Architecture Personal Assessment. The winner was Mr. Andres Mettel. Congratulations!

We believe that the Enterprise Architecture Personal Assessment is a valuable addition to our Enterprise Architecture Personal Development programme and helps those in Enterprise Architecture teams better understand themselves and importantly how they interact with other EA Team members. It can also help you formulate a road map into how you can achieve your professional development roadmap. To read more about this service please see the following link:


If you have any questions about how you can get up to speed with ArchiMate 2.0 or if you are interested in how you can build Effective Architecture Teams please contact [email protected]

On behalf of the team at Architecting the Enterprise

Catherine Green

Sales Account Manager EMEA

Join us at The Open Group London October 2013

September 25th, 2013

Architecting the Enterprise are delighted to be a premium sponsors at next month’s Open Group Conference in London.

 TOG London


While the early booking discount offer is now closed, as a contact of Architecting the Enterprise, we are excited to offer you the opportunity to attend the conference and top up your professional development by undertaking the ArchiMate 2.0 certification training.

This is a great chance to combine your attendance to the conference as a non-member of The Open Group where you will network with industry experts in business transformation using Enterprise Architecture with a fast track certification training course in ArchiMate® 2.

ArchiMate 2.0 is an open, standard modelling language specifically for Enterprise Architecture.
This allows Project managers, solution architects, business analysts, and enterprise architects to have a consistent language, in order to understand strategic change decisions.

Serge Thorn one of our world class experts and contributor to the ArchiMate Forum will be on hand to deliver this training.

To avoid disappointment book your place now as there are limited spaces. You can do this by contacting us for the registration code at Architecting the Enterprise on +44 (0) 2081 229150 or [email protected].

If your Organisation is a member of The Open Group please let us know, to unlock the members code to the conference and this ArchiMate 2.0 training opportunity.

The Open Group conference is coming to London – are you ready?

September 4th, 2013

October 21st to 24th 2013


It gives Architecting the Enterprise great pleasure to announce that we are one of the premium sponsors for the next Open Group conference in London.  We will be partnering with one of our major clients to deliver a keynote address on One World Framework and we have negotiated two special offers for our network of clients and partners for this event only.

  • Offer 1: Combine your conference attendance with a professional training course. We will be delivering ArchiMate 2.0 fast track certification training giving you a saving over £700 on the conference & training/certification fees.

The ArchiMate 2.0 course will take place on 24th and 25th October
Find out more  or contact [email protected]

We will flying in Serge Thorn one of our world class experts from Switzerland to deliver this training


  • Offer 2: Our clients who are non members can take advantage of the affiliate early bird rate if you quote LON13-ATE. For more details regarding the rates, please visit


Please book your places fast as the ArchiMate course has limited spaces.

The early bird registration ends on the 13th September 2013


The benefits in attending

Industry insight: The event program is peppered with real life practical war stories from professionals who are willing to share lessons learned with the challenges presented whilst delivering business transformation projects.

Formal and informal networking: Plenty of opportunity is given to speak with a network of peers and knowledgeable experts, bringing the obvious rewards in developing new business communities.

Enterprise Architecture Professional Development: Invest wisely by combining the conference with the ArchiMate 2.0 professional development days and ensure you are using the latest and most effective techniques for today’s Architect.

Caroline 1

One World EA Framework for Governments – The Way Forward

Judith Jones – CEO of Architecting the Enterprise

Andrew Tucker – Head of IT Strategy & Architecture, DWP, UK Government

Monday 21st October 2013

We are also delighted to announce our CEO Judith Jones will be partnering with Andrew Tucker to deliver a keynote speech at the conference

The world’s governments are developing their global thinking and harmony in working towards common goals for the environment, trading standards and economic stability and prosperity for all as set out outlined in the G7 and G8 Summits and many other collaborative networks. Governments are learning that they need effective Enterprise Architecture to make their policies reality and they need industry to support them in doing so.

How will a One World EA Framework achieve aspirations to effectively manage climate changes & impacts, global education, global e-commerce, global food challenges, healthcare challenges, tackle cybercrime and many other global issues? One World EA framework looks at how we meet these challenges, and suggests ways forward that Enterprise Architects can make a difference in assisting governments to meet these future challenging goals.

In 2013, the UN awarded South Korea a UN Public Service Award for their innovative use of Enterprise Architecture and savings of circa $400 million in their e-government initiatives which has placed them first in the United Nations survey on e-government family.

In the same survey the UK Government is established as the number 3 in e-government development worldwide. The Department of Works and Pensions (DWP) is a leader in the development of UK e-government using Enterprise Architecture and have played a major role in developing the Enterprise Architecture for UK Government as a whole.

This joint session describes the successful progress made by governments and their agencies with Enterprise Architecture and the role that EA Frameworks play and where they need to develop to play a significant role in the future.

Andrew Tucker, Head of IT Strategy and Architecture at DWP, will explain DWP’s role with Enterprise Architecture and also the Government EA Framework leadership approach to create Federated Enterprise Architectures in the UK Government.

Key takeaways:

1. Where Government EA Frameworks are successful

2. DWP leadership in Enterprise Architecture

3. How to build on the success for future global challenges

4. The Way Ahead for a One World Framework

Caroline 2

I will be at the conference, please do contact me if you wish to set up a meeting to discuss our Enterprise Architecture Professional Development Program for your organisation.


Caroline Byford – Head of Sales @Architecting the Enterprise

Email: [email protected]

Tel:+44 (0)208 1229 150

This is the Last Stop – It’s Time to Swap

August 29th, 2013

There are a number of dynamics that improve the prospect of completing information technology projects within pre-determined time, cost and quality parameters. Compliance with organizational needs using an approved standardized framework is one key factor that will enhance success and there are several EA frameworks to choose from – TOGAF addresses organizational needs and facilitates the building of the right architecture for an organization.

TOGAF has long been recognized for its ability to provide a process for developing architectures.  TOGAF 9 has built on this and has enhanced the frameworks consideration of architectural work products to ensure the process produces consistent outputs. In keeping with the scope of Enterprise Architecture TOGAF 9 is focused on holistic enterprise change and greater usability within an organization.

It’s not surprising then that TOGAF has emerged as the leading framework of choice for companies and Governments alike around the world with over 300 member organizations belonging to the Open Group.

Shaun Aug 1

In keeping with this, TOGAF 9 provides a clear path for professional development and credibility to employers. The market for Enterprise Architects is growing and TOGAF 9 certification is often a stated requirement. The latest TOGAF 9 certification status report from The Open Group supports this trend, showing the accelerated rate of individuals becoming TOGAF 9 certified since its launch in 2009.

Many TOGAF 8 certified professionals may not realize that if they have not already upgraded to TOGAF 9 the only route after 31st October 2013 is to complete the full TOGAF 9 course. An alternative to reading the 690 page TOGAF 9 book would be to take our Online Bridge Upgrade or Webinar Bridge Upgrade should you be interested in becoming TOGAF 9 certified. These courses generate a faster delivery of learning; can be accessed from your computer wherever you are in the world, enabling the course to fit around your hectic agenda.

If you are interested in upgrading to TOGAF 9 or have any questions that you wish to ask then please contact Shaun Warner.

[email protected]

Direct Dial +44 1400 567 002

Image courtesy of The Open Group. (2013). TOGAF 9 Certification Status July 2013.

Using CMU/SEI Quality Attribute Workshop (QAW) while developing an Architecture Vision

August 29th, 2013

Business Scenarios are a proven technique to link business requirements to architectural models. According to TOGAF a Business Scenario is a description of:

  • 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”

Recently I have been working with another technique which is commonly used by Software Engineering People but mainly for Software Architecture: Quality Attribute Workshops (QAWs) from CMU SEI (Carnegie Mellon Software Engineering Institute. This technique make use of interactive workshops with the main stakeholders of a project. Where you the solution is to be developed either internally or externally (not a COTS), then this technique could be combined with the Business Scenario.

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

QAW defines two kinds of architectures:

  • 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

The TOGAF specification considers the Enterprise as a System, however the term System in QAW is more related to IT Systems. QAW provides an opportunity to gather stakeholders together to provide input about their needs and expectations with respect to key quality attributes that are of particular concern to them. A similar concept to what we try to achieve with the TOGAF Business Scenario but with a focus on IT systems quality attributes.

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.

Serge Aug 1

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)


The QAW provides:

  • Increased stakeholder communication, an informed basis for architectural decisions
  • Improved architectural documentation, and support for analysis and testing throughout the life of      the system

And the results include:

  • A list of architectural drivers
  • Raw scenarios
  • A prioritized list of raw scenarios
  • Refined scenarios

During the workshops the Stakeholders receive a “participant’s handbook” providing example quality attribute taxonomies, questions, and scenarios.

Below are the steps of the QAW.

Serge Aug 2

Serge Aug 3


Serge Aug 4

Serge Aug 5


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

These elements may also be produced in a Business Scenario or produced later in the ADM phases A : Architecture Vision, C: Information Systems Architectures (stakeholders management and taxonomy of artifacts).

Serge Aug 6

The outputs from the QAW can be summarised as:

  • A list of      architectural drivers
  • Raw scenarios
  • A prioritized list of      raw scenarios
  • Refined scenarios
  • Questionnaire

Quality attribute requirements are the means by which a system is intended to meet its business goals and QAW helps to document them.

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.

Serge Thorn,

CIO Architecting the Enterprise

Ask the expert

Architecting the enterprise offers support and answers to any questions.

Send your question by email to [email protected] . Please include your name, general location, and email address. Questions may be edited for clarity.

Architecting the Enterprise education services include                                                         


Aktywne lato z Architecting the Enterprise (Polish Article)

July 30th, 2013

Prześlij do końca października 2013 zgłoszenie na któryś z kursów organizowanych przez nas w Polsce i skorzystaj z 25% obniżki ceny kursu*:








* Promocja dotyczy wyłącznie ceny za kurs.
Do ceny kursu należy doliczyć cenę odpowiedniego certyfikatu / vouchera jeśli celem jest uzyskanie oficjalnego certyfikatu The Open Group.
Ta oferta nie może łączyć się z innymi zniżkami i promocjami

Szczegółowy kalendarz kursów dostępny jest tutaj.

Co zyskujesz:

  • szkolenia przeprowadzane przez najlepszych i najbardziej doświadczonych instruktorów w Polsce (prowadzimy szkolenia z TOGAF® w Polsce nieprzerwanie od września 2006 roku)
  • przygotowanie do egzaminu – w drodze ćwiczeń indywidualnych i grupowych, quizów
  • dostęp do naszego systemu e-learningowego w celu realizacji „workbooka” kursowego
  • darmowy dostęp do kursu Enterprise Architecture for Telecoms (Foundation) Online o wartości 99 USD
  • USB Stick zawierający materiał kursu w postaci slajdów pdf, white papers, materiały referencyjne, specyfikację TOGAF® lub ArchiMate® (odpowiednio)

Architecting the Enterprise od lat jest globalnym liderem szkoleń w obszarze Architektury Korporacyjnej – w tym zwłaszcza dotyczących TOGAF®, zawdzięczając należne uznanie bezpośredniemu zaangażowaniu w prace The Open Group i udostępnieniu ich wyników tysiącom architektów na całym świecie. Kolejnym elementem jest akredytowany przez The Open Group kurs ArchiMate® 2 for Practitioners, który w połączeniu z The ArchiMate® 2 Certification Day prowadzi do uzyskania certyfikatu ArchiMate® 2 Certified.

ArchiMate® 2 jest otwartym, nowoczesnym językiem modelowania, pomyślanym od swego powstania, jako język modelowania architektury korporacyjnej. Doskonale uzupełnia ramy architektoniczne TOGAF, pozostając jednak od nich niezależnym i można go stosować również w innych środowiskach.

Pytania i komentarze prosimy kierować do:

[email protected]

tel. +48 22 3549293

Measure for Success

July 30th, 2013

Do you plan regular Architecture Capability Maturity Assessments using a model? If not, these should provide a framework that represents the key components of a productive Enterprise Architecture process. A model provides an evolutionary way to improve the overall Enterprise Architecture development process that starts out in an ad hoc state, transforms into an immature process, and then finally becomes a well defined, disciplined, managed and mature process. The goal is to enhance the overall odds for the success of the enterprise architecture by identifying weak areas and providing a defined path towards improvement. As the architecture matures, it should increase the benefits it offers the organisation.

Using the Architecture Capability Maturity Model from TOGAF® 9.1 is a great way of evaluating the way companies have implemented the framework and to identify the gaps between the business vision and the business capabilities.








Architecture Capability Maturity Assessments help to determine how well companies are prepared to

  • Maximise competitive advantage
  • Identify ways of cutting costs
  • Improve the quality of services
  • Reduce time to market of new services

We know that good Enterprise Architecture develops effective change management, maximises re-use of data, identifies and corrects inefficiencies with compliance to governance and best practice standards but for Enterprise Architecture to strive to reach a higher levels of maturity it needs to be assessed. To realise the most value from this we recommend that this should be accomplished independently and without bias.

Part of an Architecting the Enterprise, Architecture Capability Maturity Assessment is the calculation of a maturity score based on CMMI which can be broken down into 18 key process areas with a score for each. Architecting the Enterprise can then report to the Organisational stakeholders with strengths, weaknesses, gap analysis and perhaps most importantly recommendations for the next steps.

It will indicate the organisation’s maturity in the area of enterprise architecture and highlight the practices on which the organisation needs to focus in order to see the greatest improvement and the highest return on investment which is critical, when resources are limited and budgets are tight.

If you want to measure your success and uncover valuable information about how you can close the gaps between your Enterprise Architecture and your Business vision, using recommendations from an impartial organisation who lead the way in TOGAF, please contact Catherine Green for more information.

[email protected]

Direct Dial + 44 1400 567 013

Image courtesy of [renjith krishnan] / FreeDigitalPhotos.net

How to convince decision-makers to employ an architectural approach?

July 30th, 2013

One of the basic difficulties in initiating works on an enterprise architecture is to convince decision-makers to this idea. Very often, they ask about benefits this concept may bring to the organization, and about costs. Existing architecture frameworks (such as TOGAF, a de facto standard) stress the necessity of defining the so-called Value Proposition but they do not give any guideline how to do that.

The important thing is that the deployment of enterprise architecture can take two forms:

  • constant (continuous) use of architecture practice – encompassing the whole organization or its fragment (the so-called Enterprise); architecture practice becomes then an element of organizational culture, and it affects all the undertakings within the whole organization (or its previously defined fragment). Most frequently, this practice focuses on activities within particular organizational structure (such as office or department).
  • temporary (periodical) use of architectural approach in the organization – for purpose of some temporary undertaking, for example a transformation program; once the undertaking is completed, architectural approach can be embedded  into the organization (take the form of architecture practice) but it can be also not used anymore – it will depend on a decision of the organization’s board/management.

The introduction of these two forms causes that we should consider two paths of the development of a model for delivering value from the deployment of architectural approach. In this article, I am going to present the first one. It will be based on an appropriately adapted  concept of a business model.

At the moment, the bibliography gives very different definitions of how to understand a business model. One of them is as follows (according to M. Porter’s works): this is a very general description of how the organization works (who, what, to whom, how, at what cost, at what price) to create value in the organization and deliver it to its customers. Currently, the most popular definition of a business model was given by A. Osterwalder. He developed and described in the book „Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers” a methodological instrument named Business Model Canvas. The structure of a business model proposed by this author is built as a sum of assets and activities which are organized and executed by the company to deliver a particular value to a particular customer. The central part of A. Osterwalder’s model is the so-called Value Proposition. This is where an income part and a cost part of business for particular customer groups are concentrated. These parts are ordered by the author regarding some key elements, such as distribution and communication channels, methods for building relations, key activities, key assets, key partners, income streams and cost structure.

A. Osterwalder’s approach was later extended by R. Kołodziej in his work Business Model Canvas 2.0 which introduced the following modifications:

  • He added the component Job To Be Done. R. Kołodziej believes that „the source of any solutions presented to customers is job which should be done by a customer; this job determines actions for which a product or a service is acquired or can be acquired”.
  • He added the component Outcome to be Achieved. R. Kołodziej stresses that „any   Job To Be Done must bring some outcome; outcome is a measure which is used by a customer to assess the quality of doing some job for them – thus outcome is strictly related with the done job; a simple job expected by a customer can have one outcome, but a complicated job, involving many elements and consisting of many steps, can bring many different outcomes”.

When we consider building constant architecture practice, a model for delivering value from the deployment of architectural approach consists of 14 components which should be filled in with contents in a specified order – see numbers in Fig. 1. The order shown is only  an example – it should be suitable for the context of the organization. Furthermore, an iteration-based approach is assumed here – when filling in the model with contents and also later. What is more, periodical reviews and updates of the complete model are also highly  recommended.

With regard to TOGAF, this model should be filled in during the initial phase of the ADM cycle, and it should be systematically reviewed on the completion of each ADM iteration.

A person responsible for the development of such a model is the chief architect, and this document should be approved by the organization’s board/management.











Figure 1. Model for delivering value through a continuous architecture undertaking

Below, we can find a brief description of the model components:

1.                 Architecture product/service consumers – roles which will (potentially) use products/services delivered by the architecture team should be identified – it could the IT director or a head of the business process optimization department.

2.                 Jobs to be done by architecture product/service consumers – main jobs to be done by potential architecture product/service consumers should be identified. An example of such jobs may be the reduction of IT expenses – for the IT director, and the centralization of selected processes – for a head of the business process optimization department.

3.                 Outcome to be achieved by architecture product/service consumers – final outcomes to be achieved by architecture product/service consumers should be identified, for example the minimization of costs of the integration of new IT systems with the existing IT environment.

4.                 Key limitations for architecture practice – key limitations for the creation of architecture practice should be identified, for example long-term outsourcing contracts, legal limitations (for example in public sector organizations) or guidelines given by the foreign owner (in case of international groups).

5.                 Benefits of the deployment of architectural approach – the central point of model – this is a promise  made by the architecture team that embedding architectural approach into the organization will bring certain benefits. It could be a promise to simplify the integration of systems through the management of ordered and codified knowledge about relations between them.

6.                 Architecture practice key partners – a partner (support) for the creation of architecture practice; it could be a company delivering IT tools (architecture repository); an internal partner could be for example the IT department responsible for the operation of LAN/WAN, whose responsibility will be to deal with network issues related with the operation of architecture repository.

7.                 Architecture practice KPI – architecture practice KPIs should be identified; in case of the integration of systems it could be a percentage of systems for which information about its interfaces (if they are connected to other systems) was used.

8.                 Key architecture products/services – products and services which will be delivered by the architecture team should be identified; it could be for example a map of systems with the described interfaces (at logical and physical levels).

9.                 Architecture practice operational model – it should be identified how an architecture practice operational model will look like, i.e. whether architecture process will be centralized or distributed across the organization, whether information exchange between particular architecture teams will be actually present or not; this point is important for the deployment of architectural approach in large organizations of federal structure or when architecture practice is implemented in a couple of countries.

10.              Channels of communication and delivery of architecture products/services – it should be identified how architecture products/services will be delivered. It could be for example a wiki portal presenting properly developed models, PowerPoint presentations, etc.

11.              Key architecture practice-related activities – the most important architecture processes/procedures should be generally identified; an example of an architecture process could be an analysis of whether new systems are compliant with the organization’s standards.

12.              Key architecture practice-related bodies, roles and responsibilities – key architecture practice-related bodies and roles should be identified and certain responsibilities should be assigned to them (for this purpose the RACI technique can be used). An example role is chief architect, and their responsibility is the creation of a architecture review report.

13.              Key architecture practice-related risks – a record of architecture practice-related risks should be kept. An example risk could be lack of architecture competences in the organization.

14.              Architecture practice-related cost structure – by gaining knowledge about components described in points 1-13, structure of costs related with the deployment of architecture practice can be identified, and in some cases first evaluations can be possible. One of the parts of cost structure will be for example training courses for the architecture team.

The development of a model for delivering value from the deployment of architecture practice on the basis of the proposed approach cannot directly answer the question „how much we will earn/gain” thanks to enterprise architecture. Yet, it will show the relation between expected benefits (component 5) and how architecture practice is organized in the organization (components 8-12) in a consistent manner (and expressed through ideas comprehensible for    business). This model should be interesting for organizations which think about the deployment of enterprise architecture, or already have a team responsible for that but want to make some improvements.