jueves, 27 de noviembre de 2014





There are many different maturity models that can be applied to evaluate your enterprise architecture practice. Most of them make some attempt to measure the quality of your artifacts, the thoroughness of your enterprise modelling, and the rigour of your architectural processes. For educational purposes, we can simplify the maturity models a little bit. At Web Age, we've come to divide the journey into three stages that cover the beginnings of a workable architecture practice. These stages are essentially enabling stages: They let you get going with architecture, but then you need to practice architecture in your particular organization to further develop your architectural maturity. These are the phases where generalized training is useful. Put another way, you first need to have generalized capabilities (which can be taught with generalized training), and then you can develop capabilities that are specific to your organization (which would typically need to be propagated within the organization through customised training).

The generic stages are:

  • Just getting started.
  • Equipping Domain Architects
  • Establishing a Community of Practice

Let's have a look at each of these stages in turn...

Just Getting Started

To understand this stage, it's useful to remember that the drive to create an Enterprise Architecture practice usually arises out of dissatisfaction. When we ask people "Why are you interested in EA?", the answers usually boil down to "we have a lot of systems that don't work well together (or aren't maintainable, or are obsolete, or don't meet the users' needs, etc), and we wish we'd done things differently so we didn't end up in this situation. We have a feeling that Enterprise Architecture would change things".

At this stage, we need to help people understand what Enterprise Architecture is, and how it can help move us from the status quo to a more favourable "to-be" state. Usually the "to-be" state can be described as "we have a functioning business supported by appropriate software systems". We also need to define and communicate the relationships between Enterprise Architecture (EA), Solution Architecture (SA), and Technical Architecture (TA).

Generic courses at this stage will have titles like "Architectural Thinking", " Architecture Foundation", "Introduction to Enterprise Architecture", and "Introduction to Solution and Technical Architecture"

Equipping Domain Architects

Once we have a handle on just what EA means, we can start equipping architects to execute an EA program. In the same way that physical architecture (i.e. of buildings) is decomposed into Mechanical and Electrical Engineering specialties, Enterprise Architecture is often decomposed in more specialized areas, or "Domains". The most popular classification system divides EA into "Business Architecture", "Data Architecture", "Application Architecture", and "Technology Architecture".

Business Architecture and Data Architecture are self-contained domains, and training will be focused on these domains in a stand-alone way. Course tiles here would be things like "Introduction to Business Architecture", "Logical Data Modeling", and perhaps "Introduction to Big Data" or "Introduction to Data Science".

Application Architecture and Technology architecture are naturally slanted more towards particular solution architecture styles and technologies. So the training would be chosen from various areas including "Service Oriented Architecture", "Master Data Management", "Business Process Management", and "Message Oriented Middleware", as well as technology-specific areas like "Java Enterprise Edition", or "Introduction to AngularJS".

Also, if you've chosen a particular EA framework, like The Open Group Architecture Framework (TOGAF), you will want to provide the appropriate training to practitioners.

Establishing a Community of Practice

With core skills established, the EA group can now begin to practice EA and promote EA outside the EA group. In other, words, EA needs to engage the business.

Recalling that EA grows out of dissatisfaction with the current state of business and technology convergence, one might imagine that the business would embrace EA whole-heartedly. One would be wrong. Inevitably, the status quo is a result of ingrained practices and attitudes. While it's usually true that one or more executives or business managers "gets" EA and wants to embrace it, the early vanguard needs to sell EA to the rest of the organization.

We recommend a three-pronged approach:

First, training courses like "Architecture for Executives" and "Architecture for Managers" can be used to educate people outside the EA group. In addtion to the plain training value, an outside instructor can bring "expert power" that lends credibility to the Enterprise Architecture practice.

Second, architects should engage the business one-on-one and in groups. Courses like "Architecture Soft Skills" can equip architects with the selling, negotiation and persuasion skills that are needed to promote an integrated approach to EA.

Third, EA needs to be successful, and to encourage, demonstrate and document that success through an adequate governance program. A course like "Architecture Governance" can illustrate how to design an appropriate governance system and promote EA throughout the organization.


Once you've covered these generic education phases, you'll be in a position where your EA practitioners are developing governance, instituting processes and procedures, and actively engaging the business organization, as well as the broader Information Technology (IT) organization. You can think of the business, development community, and solution architecture community as "clients" of Enterprise Architecture.

Now your training needs will be two-fold: You need to develop organization-specific training to promote specific EA programs, and you need to continue promoting and propagating general knowledge and acceptance of EA.

Depending on the size and capabilities of your EA group, you might choose to develop the organization-specific training in-house, or engage a service provider like Web Age Solutions to develop and customize your in-house training program. In addition, short overview courses like "EA for Managers" or "Introduction to EA" can be offered to EA's clients.

One interesting aspect of this stage is that the size of audience increases, while the level of direct interest decreases. As such, the educational approach can be less contact-intensive. In particular, this is a perfect opportunity to use tools like self-paced e-learning. For bespoke training, you can make a single, manageable investment in training materials and then use those materials throughout the organization. For more generic topics, you can invest in tools like Web Age's "Architecture Fundamentals" On-Demand video series, which EA's clients can view at their own pace, and as frequently as needed.


A successful Enterprise Architecture program engages stakeholders and architects in a process that moves the organization from an "as-is" state (that is considered unacceptable or unsustainable for a variety of reasons) to an improved "to-be" state (that usually involves "a funtioning business supported by appropriate software systems").

Enterprise Architecture needs to be supported with training programs that are geared to the initial stages of maturity - "Just getting started", "Equipping Domain Architects", and "Building a Community of Practice". These initial training programs are often done in small groups, led by an instructor, who brings an outside perspective and lends credibility to the EA program.

Once the initial stages are accomplished, the focus shifts to promoting and practicing EA. In these later stages, a combination of in-house development and bespoke training materials may be needed, along with more scalable (if lower-touch) programs like e-learning and self-paced video training.

No hay comentarios:

Publicar un comentario