Gartner Enterprise Architecture Summit, London 14-15th May 2013

May 19th, 2013

 

This month, a team from Architecting the Enterprise enjoyed two days meeting with clients old and new to discuss how we can support their Architecture teams on their personal development journey.

Caroline Byford (Head of Global Sales & Operations) kicked the Summit off for us by participating in the Summit Solution Snap Shot giving a fantastic 60 second overview of the Personal Development Programme that we have developed for those working in the Enterprise Architecture space.

EA Journey

After a busy day, we enjoyed sharing an ice cream and hearing about your plans for investing in and developing the skills of your teams. We also had many interesting conversations about the Gartner sessions which had proved to be both thought-provoking and informative.

A reoccurring theme from our discussions was the best way to complement existing technical skills by working to improve the communication between IT and Business areas of the Organisation. This can be addressed by participation in our Elevating Enterprise Architecture training where delegates will learn more about effective communication, working in EA teams and stakeholder management. Delegates also work on creating a Value Proposition to support their projects thereby improving the chances of a successful EA programme.

Delegates can also further enhance this training by taking a one-to-one personal assessment giving them tools and techniques to support their strengths and overcome their weaknesses.

Finally, a big thank you to all of you who made the time to come and talk to us. We hope to see you at the next Gartner Enterprise Architecture Summit in London on the 21st – 22nd of May 2014 and we look forward to hearing about your successes!

In the meantime if you would like any further information please contact sales@architecting-the-enterprise

 

Catherine Green (Account Manager EMEA)
On behalf of the EA Summit team

The Impact of EA

May 19th, 2013

Sometimes it’s hard to see the impact Enterprise Architecture makes on the lives of people and the greater cascade of change that can occur-especially within developing economies. Recently I returned to East Africa after an absence of 25 years. I worked there back then for 6 years in the field of rural development, mainly for UN agencies. I hoped I was making an impact, but I was never quite sure. Recently I worked in a much less romantic setting – a modern mobile phone company – but I really felt the impact our work was having. This impact, although most obvious among the 20 professionals I worked with, has an incredible multiplier effect that reaches even down to those living in remote areas; those individuals whom I was trying to affect in a more direct way, all those years ago.

The mobile phone has an incredible positive disruptive power within developing economies, as many observers have noted. In 2005 22% of mobile-cellular network users were from developing economies when compared to ‘developed’ economies, in 2013 this has almost doubled to 41%*. Particularly in Africa between 2000-2012 there was a remarkable 3,606.7% growth of internet usage; the highest growth of internet usage of measured world regions **. Much of this growth has been driven by widespread access to mobile and cellular networks, in comparison to fixed lines.  Areas, formerly completely cut off, are now connected to the rest of a nation. Farmers can access information on the best times to plant and sell their crops. All manner of commerce moves faster and more smoothly. The company I worked with –for the purpose of this article let’s call them TeleBest, even gives out micro loans to create small businesses to sell phones and services.

By the time the course was over, TeleBest enterprise architects had developed 20 artifacts in the business, data and application domains of their corporation. These artifacts,  will after further refinement give TeleBest the basis of a five year EA roadmap. This roadmap will add or improve capabilities in such areas as customer identity management and self-service. Not only will these capabilities increase the profits of the mainly East African-owned company, it will expand employment opportunities within the company and in related enterprises. The price of service will go down and its availability expand. The multiplier effects I mentioned above will multiply even further.

My experience with TeleBest emphasized the transformative effect that I know good EA can have not just on individuals -but through the power of mature architecture- whole communities.

*Per 100 inhabitants. Figure an approximate from ITU data http://www.itu.int/en/ITU-D/Statistics/Pages/stat/default.aspx)

** http://internetworldstats.com/stats.htm

Why Your EA Initiative Is Likely To Fail

May 17th, 2013

One of my colleagues recently shared an interesting paper with me entitled, ‘Why Two Thirds of Enterprise Architecture Projects Fail’.  The report, compiled by Sven Roeleven publishes the findings of a study completed by Rotterdam University.  During the survey, 161 respondents from 89 organisations representing a range of industries where questioned about implementation of the enterprise architecture concept.  And, as the title suggests, the results were not overly encouraging.

I will embed a link to the paper at the end of this article but first, I wanted to draw attention to what for me, is a list of typical sources of failure that are widespread throughout any change process.

Many of those responding to the survey cited reasons for EA project failure as:

1.  Not enough support from C-level (CIO and CFO for example) so that EA is not given enough status and expectations cannot be fulfilled in practice.

2.  Limited commitment from interested parties so that there is a return to old habits, and agreements are not complied with.

3.  Not enough EA awareness among interested parties inside the organisation. EA is not a generally accepted concept in daily business activities.

4.  Financial and political issues that thwart EA projects.

5.  Setting up an architecture [practice] takes longer than expected.  This means it takes longer for the results to become visible, which means there is a considerable risk factor for EA.

Quite clearly, all five of the reasons listed above are due to a distinct lack of stakeholder engagement.  Granted, there may be an ‘Ah, but..!’ moment when it comes to number 4 (finance); but we believe that in most cases, if the value of the EA project is articulated well enough at the beginning, then sponsorship funding can usually be diverted or can suddenly be made available.

Stakeholder engagement is attributable to the ability to lead people effectively.  Therefore, Effective Leadership is key to successful business transformations in which Enterprise Architecture plays a major role.

Plainly speaking, if you can’t lead your stakeholders through and importantly throughout the process then you’re likely to fail.  Failure costs time, money and reputation.

You need to lead!

Our our Enterprise Architecture Professional Development program which includes elevating EA can and will help you.  Check out our website for further details about courses running near you.  We also offer an on-line version of Elevating EA.

Two thirds of EA projects fail.  Make sure that yours falls into that successful third and help to raise the bar for the good of the worldwide EA community.

Finally, as promised; here’s the link to the report, ‘Why Two Thirds of Enterprise Architecture Projects Fail’.

Best wishes

Keith
Professional Development Architect

Redefining traceability in Enterprise Architecture and implementing the concept with TOGAF 9.1 and/or ArchiMate 2.0

May 17th, 2013

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:

Traceability Stack

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:

May2013traceability_stack_notes

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.

May2013excel_sheet_issue

 

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.

May2013matrix

 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.

May2013trace_tool

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.

May2013traceability_stack_artifacts

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.

May2013arc_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).

May2013requirements

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:

May2013list

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.

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. The most interesting exchanges will be posted on our web site

Architecting the Enterprise is pleased to announce that we have trained over 2000 people in TOGAF® 9 since its launch in February in 2009.

Architecting the Enterprise education services include                                                         

TOGAF® 9 – UK Spring Offer

April 30th, 2013

For a limited time only, Architecting the Enterprise is offering its accredited TOGAF® 9 for practitioners (level 1 & 2) course including a combined Prometric exam voucher at the unbelievable price of £1,299. This price is sure to provide a ray of sunshine to brighten your day and usher in summer.

TOGAF® 9 is a detailed method and set of supporting resources for developing an Enterprise Architecture. Developed and endorsed by the membership of The Open Group’s Architecture Forum, TOGAF 9 represents an industry consensus framework and method for Enterprise Architecture and is recognized as the leading EA framework around the world.

The face-to-face instructor-led training courses provide an excellent teaching environment, in which learning can thrive through a combination of an expert instructor and enthusiastic participants.

You can attend this 4-day instructor-led training for the UNBEATABLE price of £1,299* and includes:

  • Training provided by some of the most respected and experienced instructors in the field of TOGAF®
  • A combined Prometric exam voucher that is valid for up to 12 months
  • Exam preparation by way of test questions
  • Access to a LMS workbook with further questions and quizzes – successful completion of this workbook leads to the sought after AtE Gold Award

Our Instructor-led training combines:

  • Formal teaching
  • Interactive discussions
  • Personal and group exercises

For more information and to register for one of the courses visit our website at : https://www.architecting-the-enterprise.com/training/TOGAF_9/spring_special/


*Price excludes VAT. Payment must be made prior to course attendance. This price offer is mutually exclusive and cannot be combined with any other offers. Payments for courses in June must be made in the month of May 2013.

Why Online? How online training can help your business develop

April 30th, 2013
Online Learning Reasons


These are the questions employees face if the opportunity arises regarding:


Online Learning Questions



Following the economic events and strategies over the last several years, the theme of many companies is “doing more with less”. When it comes to management, cost cutting and time cutting, there have always been initiatives that seemed difficult to incorporate while still delivering learning effectively.
Organizations that want to avoid the fruitless efforts of learning for learning’s sake instead consider the strategic vision of developing talent to drive overall organizational performance. The concept of “performance-driven learning” is important to effective employee development. This impacts the organization’s bottom line and gains the highest return on the learning and development investment.

eLearning is a great strategy for progressing employee development- and it is one that an increasing number of businesses are turning to. The 2011 Towards Maturity Benchmark Survey highlighted that 72% of the 600 companies found that using eLearning and mobile learning helped their businesses to become more agile when faced with change; this figure is growing. More so, developing your workforce can be critical to ensuring their retention through job satisfaction. A 2011 study by PricewaterhouseCooper demonstrated that younger workers in particular – a group sometimes referred to as ‘Millenials’ preferred career development to bonuses by 3 to 1. Thereby online training can be a cost-effective way of keeping your workforce happy and engaged whilst adding value to your business.

No matter the size or industry of a company, one of the main keys to success is efficiency: don’t do unnecessary work, don’t repeat steps and make sure that all areas of the company follow the company vision and targets.

But technology has progressed – thanks to increased internet access and the rapid evolution of mobile technology eLearning now is not what is what 20 years ago. In 2011 77% of US-based companies were using online learning to train their workforce- in 1995 this figure was only 4%. Solutions can be integrated and centralised, delivered on-the-go with formal and informal training. Online learning is the right tool to deliver those skills that will enable any company to align human capital resources with organizational objectives.

What can our online training do for you?

Our Online Learning Management System (LMS) provides a comprehensive approach and simple approach to access our content anywhere and at anytime. As well as our TOGAF product family, which is thoroughly recommended for bolstering your organization’s understanding of Enterprise Architecture we have several online products for those who may wish to further there knowledge of enterprise architecture, including:

SOA for EA Online EA for Telecoms Online ArchiMate Online

Architecting the Enterprise is hard at work to evolve and reflect the changing demands of our learners, the sector, as well as the economic landscape. Technology enables to us to do this and to help individuals and businesses achieve their goals.

Don’t miss the boat for TOGAF® 8-9 Bridge training – keep your qualification relevant for less

April 30th, 2013

Don't miss the boat for TOGAF BridgeDon’t forget that the last day that you can take your TOGAF® 8-to-9 Bridge exam is on the 31st October 2013. If you are TOGAF® 8 qualified and you want to retool your TOGAF® for the realities of today’s enterprise architecture then we would thoroughly recommend that you take the bridge exam while you still can. It is the ‘path of least resistance’ and it is cost-effective, in comparison to completing the combined TOGAF® 9 Level 1 & 2. We would suggest that if you are considering taking the Bridge course that you do so before training and examination schedules become over-subscribed closer to the date.

Our 2-day Bridge course is particularly well-established and will prepare you with everything that you need to excel at learning the newer specification, and taking the exam; as an added extra you will also gain free access to our EA for Telecoms (Foundation) Online.
We offer a diverse selection of delivery methods; from the hands-on guidance that you receive with instructor-led training to the flexible learning that training online can offer. Not to mention our webinars which offer the best of both worlds for those who like the pace and interactivity of instructor-led classes but the flexibility of being able to join a class from your kitchen table. Find out more about TOGAF® Bridge training, and why it is ideal for you.

Don’t miss the boat, complete your TOGAF® Bridge exam before time runs out and update your qualification to TOGAF 9.

With Best Wishes,

The AtE Team

Which side of the Spectrum do YOU sit on?

April 30th, 2013

We all have some idea of how we come across when we’re dealing with people.

I’m sure that the majority (if not all) of us like to think that we make a good impression – especially so every time we meet with influential and important stakeholders. We hope that we come across as personable, warm, accommodating and understanding in our dealings with others. We hope that we manage to display all of those positive attributes that influential and charismatic people have previously impressed upon us.After all, wouldn’t it be nice to be thought of as influential or impressive or as someone who makes an impact? Notice the use of attributes beginning with the letter ‘I’. Because there’s another ‘I-word’ that can quite often, hamper many technologists. And that’s ‘Introversion.’

There is no detriment in having a natural preference for introversion in any profession – at least there shouldn’t be. Research shows that on average, one in three people are introverted and further evidence suggests that introverts are attracted to careers in technology.
History is full of self-proclaimed powerful introverts that have proven to be some of the most influential and innovative people of our time – Steve Wozniak, Ghandi and Rosa Parks to name but a few.So, how do you know if you are Introverted, Extroverted or even Ambiverted? Well, commonly:

Introverts:

• Enjoy time alone
• Consider only deep relationships as friends
• Often feel drained after outside activities, even if they were fun
• Are usually good listeners and deep thinkers
• Appear outwardly calm and self-contained
• Think before they speak or act

Evidently, what you are is one thing, how others may perceive you is another. Having an accurate understanding of where you sit on the Introvert /Extrovert spectrum is vitally important when you’re dealing with people – especially when those people are key sponsors of your architecture projects or are potential future sponsors. These important people will form a personal view of you – so it helps to understand what that view may be and also, how you can influence it.

One way of finding out where your accurate preference lays is by taking our EA personal assessment (using the MBTI instrument) which includes a 90-minute private consultation. We are making this available to all of our clients who have previously taken the Elevating Enterprise Architecture (EEA) course or attended one of the EEA workshops. This offer is also extended to clients who may have taken our Sot Skills for Enterprise Architects (SSFEA) course in the past.

We hope to soon be in a position to open up this opportunity to everyone, so do watch this space or alternatively, why not consider enrolling for an EEA workshop near you, or consider taking the on-line EEA course. See our website for further details about our EEA products and we now also have a page for our EA personal assessment service.

Finally, I’d like to share with you – especially if you are Introverted; a TED talk by the brilliant Susan Cain, author of the recent New York Times best seller, ‘Quiet: The Power of Introverts in a World That Can’t Stop Talking.’Another world famous introvert and technologist Bill Gates has cited Susan’s TED talk as one of his all-time favorites.

I do hope that you enjoy it.

With best wishes,

Keith Flanagan
Professional Development Architect

Join us at the IT Architects Forum III, Poland

April 16th, 2013

Architecting the Enterprise will be sponsoring one of the most important events for IT and EA architects in Poland – III Forum Architektów IT organized by IDG Poland. Rafał Jabłonka will speak about the difficult friendship between project management world and enterprise architects, and how to organise their work and relations in the enterprise in the most effective way.


Dołącz do nas na Forum Architektów IT III, Polska

Miło nam poinformować, że Architecting the Enterprise będzie Sponsorem jednego z najważniejszych wydarzeń dla Architektów IT i EA w Polsce – III Forum Architektów IT organizowany przez IDG Poland. Jednym ze spikerow bedzie Rafał Jabłonka, przedstawiciel Architecting the Enterprise i będzie on mówił o trudnej przyjaźni pomiędzy Zarządzaniem Projektami a Architektami Korporacyji, a takze jak zorganizować ich pracę i relacje w Korporacji w sposób najbardziej efektywny.

Evolving Your Modelling Practice

March 27th, 2013

In this issue, we will discuss some good practices for developing your architecture. Here is a simple 4-point framework I have put together to summarise the practices that I’ve seen around. These are simply sketches and pointers to what constitutes a good architectural practice.

Modelling Picture

Vision Phase: At this initial phase, there are lots of requirements driving change and the approach to achieve set goals. You will want to understand the relevance of your architecture modelling, in terms of its role in the change programme and the level of influence you can wield. Also ensure that you’ve received requirements and conducted assessments of the current state of the organization to ensure that you have ascertained the level of organizational readiness to embark on enterprise architecture. In achieving these, remember that visualisation is a powerful tool to wield. Architecture is a collection of perceptions of many individuals. It mirrors the true state of an enterprise because it reflects cohesive organizational values, and especially, in times of transition, you can tell what shouts louder. So, ascertain the value of using the ArchiMate® modelling language, to bring these perceptions to life. Use the concepts from the ArchiMate® 2.0 Motivation extension to reveal what the true and realistic goals are, and more essentially, how they highlight your constraints, which could be either at an organizational level, infrastructure level, financial, regulatory, or social influences. Do not underestimate the power of an individual stakeholder to influence change within your organization!

Design Phase: At this phase, you want to choose your team or identify with a preset team, and then define your working standards. Get your team trained up to industry standards through one of our ArchiMate® courses, such as, ArchiMate® 2 for Practitioners. The challenge you’ll find is that most teams consist of architects and analysts with varying views on how the architecture should be represented. You’ll have to walk-through this phase to define a common understanding of the purpose of this strategy. Learn to school your team without being a ‘schoolmaster’. Decide a common vocabulary and ways of modelling your architectures, such as, your colour schema; agree and approve architecture principles and compliance mechanisms. Let your team learn restraints in modelling the entire enterprise unless required; less is more! Good modelling practice is to understand who your stakeholders are, what their concerns, interests are, in additional to relevant viewpoints that they need to see.

Modelling a directionTrade-Off Phase: You’ll need to learn the skill of negotiation. Change is not a given anywhere; people want to know why you’re switching current business process which meets the needs, to be supported by a new technology still requiring a lot of tweaking. You will also need to learn the skills of effective communication and presentation. At Architecting the Enterprise, we provide a course, “Elevating Enterprise Architecture”, which is designed to help you understand how to communicate effectively with key stakeholders, influence decisions, and recommendations for change and implementation.

Execution Phase: At this point, you would have achieved a major step where your architectural approach begins to make an impact in your organization, and almost everyone is on board…almost! Create a process whereby the models are validated by the business owners, to ensure you’ve captured key aspects to the change process. This is usually an iterative process, until the models are signed off and ready for use. Ensure you document effectively; it is important to use a tool with a good repository, so you can enforce versioning controls. Join our accredited ArchiMate® course, where delegates share their experiences in modeling and tools they use or intend to use.

Remember that there are no perfect recipes, but good practices to adopt.

All the best!


Dumebi Oderinde, PhD
Portfolio and Project Manager
Architecting the Enterprise