Strategic Architecture

Architecture standards: Wrap-up and summary

2013-03-26T19:40:00.003+01:00

This is the last in a series of postings on Architecture standards. Throughout the series we covered architecture standards from various angles ranging from business value, implementation aspects, and the operation of an effective architecture standards management practice. In this posting we will give a short summary and list the essential take-away messages from this series.

Architecture standards, why again?

The value that enterprise architects can bring to the business is to shape the design of the organization so that its components that the enterprise is broken down into in the most effective way. These components are IT related, such as applications, platforms, databases and servers. But also business related, such as business processes, roles and responsibilities, products and services. This optimal effectiveness must not only exist today, but also in the future along with the changes that an organization has to make to keep aligned with the dynamics in its environment. It is clear that this is a complex and rather challenging task because of the many factors that have an impact on strategic design decisions. A well developed set of architecture standards can be a valuable asset that supports strategic decision making. The key requirement here is that the architecture standards should be derived from corporate goals. We elaborated on how to do this in posting 4, embedding.

The use of architecture standards in change initiatives like IT projects can help to realize goals such as reusability of components and a better interoperability between systems. Well defined and documented standards make architecture governance a lot easier and a more clear process. Architecture standards help projects because it provides them with clear and tangible direction. Also a lot of expertise and know-how is encapsulated in architecture standards.

An overview of best practices

In this section we list the best practices around architecture standards management that were covered in the previous postings.

Common vocabulary

Introducing a common vocabulary has proved to greatly improve the effectiveness of our work. Words often mean different things to different people. We have good experience with drafting an “enterprise dictionary” in which we described the meaning of key terminology. Take for example the word “standard” itself. We defined a standard as the agreement that from now on some thing or best practice should always be used, most likely because its success has been proved in the past.

A clear structure

Some form of a structure is essential to be able to categorize and store standards. The structure should not be too complex but should still be powerful enough. Separating between the key content (including only the title, some key explanation and a short list of statements and properties) and the more elaborate detail has proven to be very powerful in practice. This makes that the actual body of standards looks like a deck of cards, which is easy accessible and searchable for projects. If details of a standard change, the standard itself doesn’t have to be changed.

Documentation

A coherent way of documenting standards improves accessibility and understandability of standards by its users. The templates should support the structure as explained in the previous section. We advise the use of a separate template for a standard component/rule and for a standard specification/configuration. The template for the standard component/rule also holds the meta-information for the standard such as the ownership, life cycle and version management information.

Top-down, Bottom-up

Standards should be aligned with business direction and derived from policies, strategies and roadmaps. But at the same time, standards should be in place to avoid problems that have occurred in the operation. It is clear that architecture standards do not live by themselves, but should be aligned both from a top-down as well as a bottom-up perspective.

Managing the life cycle

Once a need for standards has been identified a structured process to create the standard should be developed. Once the standard is in place, it must be properly maintained and eventually the standard should be retired when it has served its purpose and is no longer useful.

Making architecture standards work

The success of an architecture standards practice is measured by how well it is perceived by end-users that are involved in change initiatives, projects etc. There are various approaches possible to make sure that the standards are used, ranging from tough governance to begging users to kindly try to comply with at least one standard. Some best practices here that will help socialize architecture standards with its users are:

· In an early stage of a change initiative, determine which of the standards apply to the project and whether exemptions are applicable.

· Avoid “thou shalt!” but focus on how to help the project achieve its business goals effectively.

· Actively monitor and help with the use of standards during a project.

Summary

In this series we outlined what the value of a good architecture standards practice can be. We described a practical structure for capturing and documenting the key architecture standards in an organization. We also described how to manage processes around architecture standards, such as the role of an architecture board in the introduction of architecture standards, and the management of the life cycle of architecture standards. It is very important to consider that having standards is never a goal in itself. Standards should make sense in their context; they should be aligned from both a top-down and a bottom-up perspective. Only then will the enforcement and governance of the standards actually lead to a coherent, manageable and maintainable enterprise and IT landscape.

Architecture standards: Governance

2013-03-26T19:37:00.003+01:00

This is the sixth posting in a series on architecture standards. In previous postings we discussed the standards terminology, the documentation of architecture standards as well as the embedding in the organization and the life cycle of architecture standards. In this posting we pick up the thread and dive into the governance of standards.

Introduction

Architecture standards can be incredibly valuable, if they are properly managed and used in practice. This may seem obvious, but unfortunately we have seen several cases in practice where organizations develop a (large) body of standards and fail to manage and use it properly. Over time the standards base gets outdated, degrades, and loses its value at which point it will sit on a shelf collecting dust.

From this analysis, we learn that processes related to keeping the standards body up to date and processes related to governing the use of standards are two sides of the same coin. Both must be in place if we strive for effective standards management.

Keeping the standards body up to date

Keeping the standards body fresh, active, and up to date sounds simpler than it really is. At first glance, it may seem that all we have to do is to make sure that standards get a periodic review, and make sure that we have some mechanism in place to receive feedback from others on their usefulness in practice. There is, however, more to it than that. Here are some typical things to worry about based on our work in several organizations:

· Who actually approves and effectuates a standard, and who is bound by its use?

· Who owns and is responsible for maintaining standards in a certain domain. Is that one person, or a whole group?

· Do we want standards to expire after a certain amount of time (i.e., we have to schedule a review cycle for each standard), or do they only expire when some stakeholder in the organization complains that it is out of date?

· How do we make sure that our standards stay aligned with strategies, roadmaps, and policies of other groups in the organization?

Our experience is that a simple approach, in line with the TOGAF practice, tends to work best in this respect. In this approach we distinguish a number of roles in the standards management practice:

· The architecture board (AB) owns the body of standards and drives its development and is responsible to keep it up to date. Members of the AB should be sufficiently high up in the organization, typically at the director level. They take care of approval of standards and delegate work packages related to the development of standards to domain leads. This is also where expiry of standards is tracked, typically by means of an automated system that triggers when a standard is about to become outdated. See also part 5 of this series where we described the management of the life cycle of architecture standards.

· Domain leads are responsible for making sure that standards in a particular domain (such as integration, or security) are aligned with regulations (policies, strategies, roadmaps) etcetera. In posting 4 (embedding) of this series we described some guidelines and best practices on how to achieve this alignment. Domain leads are typically also subject matter experts.

· Subject matter experts (SMEs) do the actual work of developing standards. Typically an SME receives a work package to develop or update a standard after which it goes via domain lead to the AB for approval.

One other thing should be mentioned here: developing and maintaining standards take time. It is not something that typically can be done “in between other jobs”. As such, work related to standards should be managed as mini projects with proper time codes, delivery and so on.

Standards use

In theory, standards are developed as best practices and people want to follow them because they make sense. In many cases this is indeed the case. We have seen several examples where standards around complex security services were followed automatically by everyone in the organization because they made so much sense: figuring out other ways to implement security requirements that are covered by the standard would just take too much time and hassle and thus no one bothered to do so.

In other cases, though, we see the exact opposite.

Unfortunately this typically tends to be the case with standardized technology. Exaggerating slightly: it appears that every project wants to reinvent the wheel and bring its own specific new and cool toys into the organization rather than using the standard.

We have seen cases where organizations have several different database platforms, ETL tools, and even ESB’s leading to a dispersed landscape as well as high cost around licensing and maintenance.

The key to success in this area is to make sure that everyone in the organization understands that standards management only makes sense if we maximize the return on investment by actually following them. This may require a lot of evangelizing and collecting of hard data. In the end it is worth it! Eventually the goal should be to make sure that following standards is second nature for all key stakeholders (sponsors, project managers, business owners and so on), while still taking into account that exceptions to the rule do occur in practice!

There are also several practical things that can be done to be successful in this area:

· First of all, every project deserves an architectural intake. The goal of the intake is to figure out which of the standards apply to the project and whether exemptions are applicable. We briefly mentioned the selection of standards for a project in part 3, where we also mentioned that it is important to keep track of which standards were selected for a project.

· Be careful of “thou shalt!” architecture in that respect: focus on how to help the project achieve its business goals effectively.

· During the course of a project, actively monitor and help with the use of standards.

· Especially for IT-related standards: develop a strategy for handling standards compliance of systems that are in production. Some rules (i.e. security) must always be followed. However, it may not be a good idea to upgrade the entire application landscape to the latest version of a standard platform.

Getting started

Last but not least, a few tips on getting started with standards management. First of all, experience shows that it is best to “think big but start small”. Start in a small area and start showing value, building the standards practice as you move along. Indeed, it seems that IT standards may be a good place to start. Get an architecture board in place as soon as possible. This will improve visibility of the initiative and provides a good linking pin to the rest of the organization. Last but not least: communication is a key ingredient of being successful.

Architecture standards: Life cycle

2013-03-26T19:30:00.002+01:00

This is the fifth posting in a series on architecture standards. In previous postings we discussed the standards terminology and the documentation of architecture standards as well the embedding of the standards practice in the organization. In this posting we discuss the life cycle of standards.

Introduction

In pure science, many research papers seem to start with “assume we have a model for X”, after which a lengthy discussion follows. In practice, we do not have such luxury, especially in the field of architecture standards. If we as an organization want to be successful with standards, then we better put in the work to make that happen.

More to the point: standards cannot be “magicked into existence” once a need for it has been identified (e.g. top-down or bottom-up, see the previous post in this series). It takes time to develop a standard, and once it has been developed it must be properly maintained and eventually it should be retired when it has served its purpose and is no longer useful. The “circle of life”, so to speak.

Life cycle

Setting up a proper life cycle and supporting process may seem simple at first glance. There is a bit more to it than just tracking which standards are still in draft, which are active, and which are retired, and this has everything to do with a pro-active governance process. The following diagram shows the various states and transitions that we found to work well in practice:

The basic idea is simple: first, standards need to be developed. After an idea has been articulated and while it is being developed, the state of a standard is draft. Once it is ready for approval, it is offered to some board (typically the Architecture Board – AB). The state then changes to under review. Let’s assume the board approves it.

Here we introduce a first trick: there may be valid reasons to hold back the publication of a standard for a bit. For example, we want some IT component to become the standard for some functionality, only the project that initially implements the functionality has yet to start. Therefore, we must distinguish between an awaiting publication state, which merely states that the board agrees, and a subsequent active state which means that the standard has actually been published and is now valid. The active state is actually composite as it encompasses several sub-states as illustrated by the following diagram:

First we hit the pure active, published sub-state. This means that the standard is out there, being used etc. After a while (typically time-triggered), the standard must be reviewed by the board. The state then becomes active, under review. This leads to an update (active, under revision), immediate re-approval (active, awaiting re-publication) or a decision to scrap the standard because it is now outdated. The latter means we’re moving out of the composite state to the Archived state.

Process and templates

In order to effectively manage the transition between the different states of standards, two things are needed: first of all, standards must be clearly tagged with respect to their state. This can either be done in the document itself, in a document management system, or otherwise.

However, this is not the most important part. In order to be successful, the organization must look into standards approval processes as well as roles and responsibilities. This ties directly into the world of enterprise governance which is the topic of the next posting in this series.

Architecture standards: Embedding

2013-03-26T19:27:00.000+01:00

This is the fourth posting in a series on architecture standards. In previous postings we discussed the standards terminology and the documentation of architecture standards. In this posting we pick up the thread and dive into the embedding of the standards practice in the organization. As mentioned in the introduction, well defined architecture standards do not live in solitude. The relationship between similar concepts in other parts of the organization, such as corporate strategy, policies, tech standards etc. should exist and maintained. The “art” of embedding is an important topic, because the linkages are essential but could easily lead to a rigid and complex system, inhibiting its effectiveness.

Top-down, bottom-up

In order to be successful with standards, remember that they are there for a reason. Either they emerged as a best practice, or someone in the enterprise decided that it is a good idea to make something a standard. To get started with standards, two general approaches can be followed (we describe the two extremes here, in practice organizations follow a mixed approach): top-down versus bottom-up.

A top-down approach asserts that standards are derived from policies, strategies, roadmaps etc. (abbreviated as ‘corporate regulations' for ease of reference). That is, we define standards to make sure that people who follow standards actually comply with corporate regulations.

It should be noted that these regulations tend to be high-level and need not be SMART: strategies provide a general sense of direction in a particular realm, and policies tend to be defined as directives that are not directly enforceable; they govern a course of action (see e.g. OMG’s Business Motivation Model).

On the other hand a bottom-up approach starts with issues at the (current) operational level of the organization. Upon recognition of those ‘pain points’ in the organization and subsequent support of management to go ahead, best practices are sought or developed to consistently deal with these issues.

Alignment

Recognizing that standards must be aligned to both regulations and operations is a good point of departure. It should be noted, however, that in most organizations, standards are developed from the point of view of different disciplines / departments. For a successful standards practice, these should be aligned as well as illustrated by the following figure:

When setting up a standards practice along these lines with a good balance between top-down and bottom-up, roles and responsibilities must be defined clearly. This makes sure that projects that actually use / implement standards do not have to deal with conflicting standards. In the 6^th posting of this series we will discuss how this can be achieved. However, as is so often the case, it should be noted that the key aspects to success are communication, communication, and communication. A good vehicle for making sure people aligned in their thinking is a monthly meeting of a standards council. We will elaborate on the key roles in an architecture standards practice in part 6 of this series.

Approach

The diagram above shows that the alignment of the architecture standards both horizontally and vertically involves a lot of coordination. In fact, in larger organizations each of the red arrows that appear in the diagram needs to be managed separately, because each box is often a different department with different people (and a different history in managing standards or similar concepts). In our practice we have seen that setting up a framework around this alignment needs the right mix of two main ingredients.

On the one hand side there is a need for a fairly rigid structure, in terms of bi-lateral agreements on the processes. These processes should not be too complex; however, we advise that they should be explicitly documented, e.g. by using a simple process flow. A good way to set this up is using a workshop approach in which the processes are worked out. We recommend doing this in a rather small group, e.g. one person representing one of the groups (a box in the diagram), one architect and one facilitator.

The other ingredient involves softer skills. The need to align standards throughout the enterprise needs to be socialized with other groups. This needs an indefinite amount of conversation and discussion (and coffee breaks, and lunches), and often some political savviness to navigate your way through the corporate waters. Practical tips for enhancing visibility of a standards alignment effort include sending out newsletters, organize lunch sessions, and putting up posters at some strategic spots in the offices.

Architecture standards: Documentation

2013-03-26T19:23:00.002+01:00

This is the third posting in a series on architecture standards. In the previous posting we presented some basic terminology. Most importantly, we distinguished between standard rules, and standard components. In this posting we pick up the thread and zoom in on the documentation of standards. In order to do so, we kick off this post with an analysis of how/ where standards are used, and “derive” a template from that.

Using standards in architecture work

Having a (well documented) library of standards may look impressive, but need not be very effective by itself. Indeed, we have seen organizations with close to 5000 pages of architecture standards! This didn’t even cover security standards and infrastructure standards in their full depth yet..!

Impressive indeed, but barely usable in practice! During an engagement at this organization, we learned that standards were too long and fuzzy, that nobody really knew all the standards and that governance was hard to say the least.

Since architecture helps in effectively designing and transforming organizations, standards tend to be used to either (a) help architects to their work – that is, they pertain to the process of doing architecture, or (b) help architects in making and implementing effective design choices. Therefore, the way standards are documented should be tailored to being of use in (change related) projects.

Requirements for standards documentation

In our previous posting we already touched upon the “deck of cards” approach to standards. This deck of cards is – in a matter of speaking – the “bible of governance” and should therefore be well structured, accessible, and up to date.

Standard rules and components should be separated from their associated specifications and configurations for reasons of stability, maintainability etc. This implies that the first requirement for standard rules and components should be that they are extremely to the point. In practice we have found that a maximum of two pages is generally enough. This requirement does not hold for specifications and configurations: here we document all the necessary details (controls, patterns, scenarios etc.) that projects need in order to get the job done. Indeed, we have seen specifications as large as 40 pages!

In a way, requirements for standards documentation are similar to those of architecture principles in the TOGAF standard (see e.g. our earlier series on TOGAF):

A standard document should contain a rationale (why did we decide to make this a standard) as well as a SMART statement of what is actually being standardized.
We strongly recommend that it should be made explicit how governance will take place: who will check what, and when in order to make sure that the standard is followed? This will provide much-desired clarity for projects actually using the standard.
Since we have different types of standards, relations between standards must explicitly be documented. This means, for example, that standard rules contain “pointers” to associated components and specification.
Last but not least, the usual “meta data” should be in place: when does the standard expire, who owns it, what domains does it belong to, etc.

If you’re interested in templates for standards, please get in touch via E-mail. Our contact information can be found at the bottom of this posting.

Document management

Different projects touch upon different aspects of the enterprise. Therefore, different projects need different sets of standards or a different “hand of cards from the deck” so to speak. The selected set of standards is the basis for governance later in the project lifecycle. In order to support this process of selection, it is recommended to document as part of the standard the situations or scenarios in which the standard is applicable. E.g. enterprise standards for presentational styles are applicable in every project where web pages are developed. It is also highly recommended to keep track of which set of standards each project is expected to follow.

In practice we have found that a simple DMS can be very effective for managing both the individual documents for each standard (i.e., keeping version + change logs) as well as the issue of tracking compliance of projects.

The lifecycle / evolution of standards is discussed in posting 5 of this series. Governance is discussed in posting 6.

Architecture standards: Terminology

2013-03-26T19:18:00.001+01:00

In the previous posting we have explained the benefits of having a good standards practice in place, especially in the context of enterprise architecture. In this posting we set the scene for our framework on standards management by introducing terminology that we will use throughout this series. This terminology has been tried and tested in practice, in both business and IT-related settings. We have found that standardized terminology around standards management greatly improved effectiveness of our work.

The term “standard”

The word “standard” means different things to different people, ranging from “a statement of direction” to a very detailed instruction manual on how to do or configure something. See for example the Wikipedia page on this term. Similar terminological confusion arises over words such as “technical specification”, “policy”, “strategy” and “roadmap”.

To complicate matters even more, the question of what is what is often a matter of perspective. To illustrate that point from an IT perspective, consider the following example: the fact that certain types of platforms are in use as well as selection criteria for picking the right platform would be a useful standard from an (enterprise) architecture perspective. From this perspective, all technical data on how these platforms are configured etc. are too detailed. However, from an infrastructure perspective, these details are an essential part of the standard!

A standard can loosely be defined as the agreement that from now on some thing or best practice should always be used, most likely because its success has been proven in the past. This definition is general enough to apply to the standardization of e.g. processes, types of technology, or even dress-code if necessary.

Deck of cards principle

In order to make standards useful for projects, the set of standards should be very specific and to the point. The collection of standards (the standards base) can be seen as a “deck of cards”, where each card is one standard. For each individual project we will select those “cards” that are applicable to the project. By adhering strictly to the deck-of-cards principle, the actual standards are kept short and to the point which in turns has two main advantages:

1. A smaller set of standards and selected for relevance is less likely to “scare off a project”

2. Governance is easier when standards are SMART.

Rules and Components

Considering the set of all architecture standards, two subsets can be distinguished:

First of all, there is a set of “things” that are mandated to be used in certain situations. Examples are standard tools, platforms, models, and software components.
The second subset of standards can be thought of as rules: things you should do or properties that systems should have. A typical example here is the fact that sensitive data must be encrypted with certain algorithms and a specific key length.

Since we are developing standards as a “deck of cards”, these rules and components should be short and to the point; details are documented elsewhere as visualized in the following diagram:

The specifics of a standard rule are documented in a standard specification. The following example illustrates this. In a standard rule named “data specification” it is asserted that an organizations specific naming convention should be used when making data models. The actual lists of names that are allowed are documented in the standard specification that is associated to that standard rule. There is an extra advantage of separating between the “core” of the standard, as documented in the rule, and the details, documented in a specification. If some detail changes, this change can be processed in the specification without having to put the actual standard through a whole process of revision. We will elaborate on this kind of processes in part 5 of this series.

Some of the standard components are actual tools. We tend not to use these tools “out of the box”, but we configure them in a specific way. Therefore, these configurations may be associated to standard components. For example: the standard component for architecture modeling is a tool called BiZZdesign Architect. This tool can be configured to automatically follow certain naming conventions, layout options etc. That is why a dotted relationship between a configuration and a specification is depicted in the diagram above.

Examples

Some of examples of standards at the enterprise level are:

Enterprise Security Standard:

Rule: All solutions and applications should comply with the enterprise security standards such as identity management, access management, auditing and monitoring, and information control.
Details of each of the security domains mentioned could be documented in separate specifications.
Also relationships to standard components that support the security standards can be created. The standard components refer to physical technology components that the organization chose to adopt.
The technology components are configured in such way that it meets the security standards and all the detail of it as documented in the various specifications.

Enterprise Integration Standard:

Rule: All solutions and applications should comply with the enterprise standards for service oriented architecture (SOA). All interfaces from and to software components should comply with the enterprise standards for interface definition.
Details and specifics of how the interfaces should be defined can be documented in separate specifications.
Relationships to standard components can be created. These components describe specific platforms and tools that support the enterprise SOA strategy. For example service repositories and the technology used for routing and transformation (i.e. the service bus).

Architecture standards: intro and overview

2013-03-26T19:11:00.003+01:00

Standards management plays an important role in many aspects of organizations. It is frequently seen as a way to improve costing structures, governance, IT-efficiency et cetera. Setting up a good standards practice is by no means simple and straight forward, though.

This is the first in a series of postings on Architecture standards. The series consist of seven postings each covering a different aspect of the subject. In this first posting we will explore why an organization would care about architecture standards in the first place, and also what value a good architecture standards practice can bring to the table. For the content of this series we base ourselves partly on theory from architecture frameworks such as TOGAF , documented best practices, and our own practical experience and lessons drawn from several engagements with client organizations in which we helped building an effective architecture standards practice.

Why architecture standards?

We are convinced that a well defined set of architecture standards as well as an effective standards management practice is a key asset for most organizations. Standards allow enterprise architects to become more effective by aligning with goals such reusability of components (IT related, but also business related, e.g. a business process or capability) and interoperability between systems. Having said this, we have to raise a first red flag here already: setting architecture standards should never be a goal in itself! Putting a standard in place should always have a clear and explicit rationale which, in turn, should be linked to one or more business drivers, such as lowering maintenance costs or faster development of new functionality.

How do architecture standards realize business value?

As mentioned in the previous section, each architecture standard should be aligned with one or more business drivers. These drivers are in their turn derived from the overall strategy as declared by the executive board of the enterprise. If an architecture standard falls short of such a relationship, it is a waste of effort to have and maintain it. In posting 4 of this series we will elaborate on the embedding of architecture standards with similar concepts in other places in the organization (policies, technical specifications, etc.). Below we list some benefits of a good architecture practice that directly translate into business value. These examples are drawn from what we have seen in practice, the list is definitely not meant to be complete.

· Improve efficiency of processes
Architecture standards have an impact on key design choices for new functionality. The earlier in the development process these choices are made, the better. This point is illustrated by the simplified graph, depicting how the cost of change curve for the life cycle of an IT project looks like: the later in the life cycle, the higher (more than linear!) the cost of change.

· Improve interoperability
Think of electricity plugs for your electronic equipment. If you do a lot of travelling, you know that you need a whole bunch of converter plugs to be able to plug in your laptop in all parts of the world. The same holds for interfaces between IT systems. The more standardized these interfaces are, the less “converter plugs” (i.e. band-aid solutions) are needed, the less costs for maintenance, etc.

· Reduce risk
In the next posting (terminology) we will define a standard as some “thing “ or best practice that has proven successful in the past. This past success and experience with the standard mean that reusing it in a new project improves the predictability of the result. This greatly reduces project risk of all sorts. Take for example a standard IT component that handles authorization for access to an application. It was proven in the past that this standard complies with corporate policies on identity and access management. Reusing the component in the development of a new application assures us that the new application also complies with the corporate policy. Hence the risk of a security breach is reduced.

· Lower costs (TCO)
Standardization can result in the reduction of the number of assets in the enterprise landscape. This means a reduction of the total cost of ownership.

How to use standards

Architecture standards do not exist in solitude in the organization. Beside the actual content of the architecture standards themselves, the “standards practice” comes among other things with processes for governance and maintenance, roles and responsibilities, and a common vocabulary. The success of the standards practices depends on how well all this is tied into other processes and frameworks in the organization. This will be a central theme in the subsequent postings in this series. We end this first posting with an overview of the topics of the next postings.

Overview blog series

The figure below visualizes the overview of this blog series. We will briefly explain what will be covered in each of the topics mentioned.

· Terminology
As in every management discipline, communication is a key success factor. There is a need for a common vocabulary. What exactly is a standard? What are types of standards? In this posting we will introduce a framework for architecture standards management, and explain the words that define this framework.

· Documentation
This posting describes an effective approach for the documentation of architecture standards. We will also touch up on how to store the content, and how to maintain this body of architecture standards.

· Embedding
As already brought to bear in this posting, architecture standards do not live in solitude, but should be connected to corporate strategy. In this posting we will elaborate on practical ways to achieve the right level of embedding.

· Life cycle
Change is a constant factor for every organization, and architecture standards need to adapt to changes. That means that the architecture standards have an expiration date on them, and that they should be reviewed on a regular basis. The right processes must be in place to manage the life cycle of architecture standards. In this posting we will describe a practical approach.

· Governance
An architecture standard is worth close to nothing if they are not used in change initiatives such as IT projects. A solid governance process alone is not enough, every effort should be taken to socialize and familiarize end users with the architecture standards available and applicable to them. This will be the last topic of the series, before we issue a final episode in which we wrap-up and summarize.

Covering the basics: keep track of requirements

2013-02-06T15:35:00.001+01:00

This is the last posting in a series on TOGAF’s ADM. In this final post we zoom in on the Requirements Management phase which is central to the ADM. We will start this post with a discussion of the formal objectives, steps, inputs and outputs of this phase. After that we will discuss best practices for effective requirements management in the architecture space. We will end this series by discussion TOGAF and ArchiMate integration.

Objectives, steps, inputs and outputs

The Requirements Management phase forms the heart of the ADM; all other phases interact with it. This again stresses the nature of architecture work, which revolves around structured and controlled change of the enterprise. If you want to change, you’d better have some idea of where you’re going (vision). Since this vision is not yet achieved, there are certain requirements that have to be met to get there – or at least to move in the right direction.

The TOGAF standard defines a requirement as “A quantitative statement of business need that must be met by a particular architecture or work package”. The objective of this phase is simple: to define a process whereby requirements for enterprise architecture are identified, stored, and fed into and out of the relevant ADM phases. In other words, the RM phase at the center of the ADM “crop circle” should not be seen as a static document but an active process of management requirements in the context of change.

Key activities in this phase are prototypical for the requirements discipline and involve the identification and definition of requirements, prioritization, recording requirements and priorities in the repository, identifying changing requirements and priorities as well as handling their impact etcetera. Furthermore, it should be noted that the TOGAF standard does not propose or mandate a particular form for recording requirements.

The outputs for this phase as defined by the TOGAF standard are the requirements impact assessment (asserting the impact of changing requirements or priorities) and the architecture requirements specification (see our earlier posting on ADM Phases B, C, and D).

Best practices

Getting requirements right is essential in realizing the goals of any architecture initiative. Without clear requirements, defining and realizing an architecture quickly degenerates into a guessing game.

In itself this is not new as this fact has been established in the field of software engineering a long time ago (Note: see e.g., the seminal book “the mythical man month” by Freddy Brooks Jr., published in 1975). Unfortunately, both in the field of software engineering and enterprise architecture alike, requirements management still does not get the attention it deserves. More often than not, requirements management is something “we do on the side”.

In order to be successful with requirements management in the context of the ADM, requirements modeling and architecture modeling should be integrated as much as possible. In previous postings of this series we already advocated the use of ArchiMate as a language for architecture modeling. Recently the ArchiMate language has been extended to be able to model requirements and directly relate it to concepts from the ArchiMate core.

The above diagram illustrates the use of (part of) this extension. Starting at the top, it shows a stakeholder (claim reviewer) with his concern (claim handling). Associated to this concern are three assessments which lead to the goal to revise the claim handling process. This goal is decomposed in three sub goals, two of which are realized by requirements. These requirements, in turn, are to be realized by the application service Registration Service.

This way of integral modeling has many benefits, including improved traceability, tool support (e.g. BiZZdesign Architect), advanced analysis etcetera.

TOGAF and ArchiMate integration

To finish this series we briefly discuss TOGAF and ArchiMate integration. Both standards are currently maintained by the Open Group and complement each other.

The TOGAF standard focuses on the process of doing architecture, whereas ArchiMate focuses on architecture descriptions. Both standards leverage the three domains (business, information systems, technology) and the ArchiMate concepts map well on TOGAF’s content meta-model. The development of ArchiMate – especially the recently proposed extensions for motivation and implementation & migration are focused on further integration between the two standards

Questions

We hope that you found this series of articles on TOGAF’s ADM useful and help you use TOGAF in your own organization. If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Dealing with change

2013-02-06T15:31:00.002+01:00

This is the eight posting in a series on TOGAF’s ADM which covers phase H – Architecture Change Management. Phase H is not really a phase, but more a continuous activity of monitoring change as well as establishing procedures for managing this change.

Objectives, steps, inputs and outputs

The adage “the only constant is change” most certainly holds for many businesses. It is therefore extremely important to make sure that the designed architectures continue to stay aligned to business goals and direction. The formal objectives of this phase are: make sure that the architecture continues to be fit for purpose, assess changes to the framework and principles set up in the previous phases, to establish a change management process for the new (baseline) architecture that is achieved with the completion of phase G, and to operate the governance framework.

The drivers for change will vary from organization to organization but may originate from e.g. a strategy change, resolving key issues in the current operation or experience from previous (architecture) projects.

Changes are managed by means of a Request for Change (RFC) form. Changes can be classified as either simplification changes (which can normally be handled via regular change management techniques), an incremental change, or a re-architecting change (which requires the organization to go through a whole new ADM cycle). To determine whether a change is simplification, incremental, or re-architecting, the following activities are undertaken:

Registration of all events that may impact the architecture
Resource allocation and management for architecture tasks
The process or role responsible for architecture resources has to make assessment of what should be done
Evaluation of impacts

Typical inputs for this phase are all the architecture deliverables from the previous phases (including e.g. the Organizational Model for EA, the Architecture Repository and the Architecture Definition Document) as well as formal change requests. Typical outputs are architecture updates, changes to the framework, new requests for architecture work (spinning off a new ADM cycle) as well as compliance assessments and (updated) architecture contracts.

Best practices

Based on experiences at several organizations over the last few years we have learned that the key to being successful in the area of architecture change management lies in two things: communication and participation. To operationalize this, the organization should have an effective architecture board.

The Architecture Board “should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall architecture”. If the key players with respect to architecture join forces in the board and meet frequently (bi-weekly tends to be a good rhythm) then changes as well as issues in projects can be dealt with early and effectively.

Note that the board should be used for (a) discussing new trends, and (b) making decisions. The board should delegate detailed (impact) analysis to the architecture team whenever possible to make the best use of its time.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Managing implementation oversight of projects

2013-02-06T15:26:00.002+01:00

This is the seventh posting in a series on TOGAF’s ADM. In the previous posts we zoomed in on defining a vision, modeling baseline and target architectures, finding delivery vehicles for implementing the target architecture as well as defining a set of projects to implement the delivery vehicles. At this stage, we shift our perspective to implementation governance: overseeing the projects that were defined in the previous phase.

Objectives, steps, inputs and outputs

This phase is all about oversight; meaning that “others get to do the work” and architects “check if it is done right”. In the light of the adage that no one likes a bully, the objectives for this phase are not only to govern and manage compliance to the architecture contract, but also to formulate recommendations and to obtain support from supporting organizations (i.e., operations) that will underpin the future working lifetime of the deployed solution.

In this phase, typical project details such as acceptance criteria and measures of effectiveness become more important. In assessing compliance, the TOGAF standard (in chapter 48) even defines terminology for specifying whether an implementation is irrelevant, consistent, compliant, (fully) conformant, or non-conformant. The inputs for this phase are all the artefacts that have been defined so far throughout the ADM as well as the architecture repository.

The steps of this phase include a check on scope, identification of development resources and skills, provide the project with implementation recommendations, etc. Even more, at the end of the project architecture compliance is assessed and a post-implementation review is performed in order to obtain lessons learned.

The main outputs of the phase are the signed architecture contract as well as a compliance assessment. Even more, change requests may be issued as well during implementation; e.g. when it turns out that elements proposed in the architecture turn out to be less practical than anticipated in earlier phases.

Best practices

An issue that we have frequently encountered in this phase pertains to resource planning. We often see that there are a few critical resources that are severely overloaded as they play a necessary and critical role in several projects

It is understandable that projects / project leads would all prefer to have the best staff on their team. However, as strong and smart as these champions may be, the law of raspberry jam states that attention by these champions for each individual project will be little. Possibly too little. This suggests that looking for a different resource may be the better option in many cases.

A second best practice lays in the observation that close co-operation and co-ordination of mental activities (such as defining a vision, performing impact analysis etc.) and implementation activities is necessary.

Overstating slightly, failing to get this right will result in a beautiful architecture that is “tossed over the wall” to the implementation team who picks it up and runs with it, vaguely going in the right direction. In the end, this will result in disaster when e.g., the developed solution does not link well to current processes, IT infrastructure, or results of other projects.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Translating opportunities to a well-defined project plan

2013-02-06T15:22:00.001+01:00

This is the sixth posting in a series on TOGAF’s ADM. In the previous post we zoomed in on finding opportunities that help realize a desired vision. In this post we pick up the thread and focus on translating these opportunities and solutions to a well-defined migration plan.

Objectives, steps, inputs and outputs

The objective of this phase is simple: come up with a migration plan that is aligned with other management and governance frameworks in the organization (i.e. project management approaches such as Prince2). This entails two things: (1) to make sure that work packages – based on the transition architectures from phase E – are defined and prioritized, and (2) to co-ordinate with the project management office so that the projects can be kicked off when necessary.

The inputs of this phase are numerous in the full TOGAF spec, and mostly cover the outputs of all the previous phases such as the architecture vision, statement of architecture work, architecture definition document, (preliminary) architecture requirements specification and a set of (preliminary) transition architectures. Many of these documents will be finalized in the current phase.

Following the TOGAF standard, the steps in this phase include confirming that other management and governance frameworks are aligned (i.e., project management, operations) to avoid surprises down the road; do a cost/benefit analysis based on expected business value of each of the transition architectures; prioritize; generate a time-lined roadmap and migration plan; and to establish the architecture evolution cycle as well as lessons learned. In this phase, close co-operation, buy-in, and direction from management are key in generating the desired migration plan.

The key deliverables of this phase are the implementation plan and architecture contracts for each of the proposed implementation projects. Such contract is a “joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture”. This deliverable closely resembles DYA’s “Project Start Architecture” (PSA). This document will be used in the next phase as a basis for governing and overseeing the implementation project.

Best practices

In several projects at clients, we have found that maintaining a close relation between the enterprise architecture team and a project management office is a key aspect of being successful with architecture.

Traditionally when someone in the business has a great idea, a first step in achieving it is a project lead who manages the concretization of the idea into a solid implementation plan and its delivery. When adopting TOGAF’s ADM, a large part of this work is delegated to the architecture team. In order to structurally manage the relation, roles, responsibilities between the two bodies in an organization it is useful to create an architecture board. In the architecture board, key players from the business side (executive sponsors), architects, project managers and other stakeholders meet to jointly prioritize work packages. Usually such a board only approves (or calls for amendments of) plans that are prepared by the architecture team, but in some cases (i.e., large programs and key projects under high pressure), a workshop-based approach may be called for.

A second best practice in this respect pertains to document management. The TOGAF standard proposes to use an architecture repository to track and manage artefacts produced during/ used by the architecture team. However, since projects need a formal basis, in our experience it is best to let the project management office (PMO) handle management of documents that are formally signed off. The contract can then be managed together with documents and deliverables that are used by the project methodology of the organization.

The diagram below illustrates both:

Firstly, it shows that planning & prioritization is a joint activity between different roles, and is part of Phase E of TOGAFs ADM. This phase is modeled as a process step. Furthermore, the diagram also shows that the management of formal project documentation is a function that is used in phase E. (Execution of) this function is assigned to the project manager.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Finding ways to implement the target architecture

2013-02-06T15:20:00.000+01:00

This is the fifth posting in a series on TOGAF’s ADM. Following the ADM, we have so far prepared the organization for doing architecture work, defined an architecture vision and modeled baseline- and target architecture. In this post we zoom in on phase E: Opportunities and Solutions in which we find the delivery vehicles for implementing the architecture. As before, we briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Objectives, steps, inputs and outputs.

The primary objectives for this phase are to (a) consolidate the gap analysis for the three domains, (b) to find groups of building blocks to address the capabilities that address the missing capabilities. To understand what happens in this phase, a solid understanding of the building block concept is necessary.

Sidebar: building blocks

Simply put, a building block (BB) is a cohesive unit of functionality and can be either a business capability, (part of) an information system, a piece of infrastructure or a combination thereof. BB’s are loosely coupled and can generally be realized independent of other BB’s, often in more ways than one. Note that a distinction between architecture building blocks (ABB) and solution building blocks (SBB) are made. The former capture architecture requirements from the relevant domains, whereas the latter specify what components will implement these requirements. More details can be found in section 37 of the TOGAF 9 specification.

The inputs to this phase are numerous: all the architectural artefacts developed so far are used and analyzed to form a coherent view of the exact capabilities that are to be delivered. Heavy use is being made of the architecture repository in this phase: specifications of BB’s are used in conjunction with case studies, vendor information, implementation strategies and so forth.

The TOGAF standard proposes to use a tabular form for gap analysis, where the vertical axis lists the baseline BB’s and the horizontal axis lists target BB’s. Analyzing rows and columns effectively means comparing baseline and target architectures. The following diagram illustrates how this works:

Gaps between baseline and target may result from each of the three domains:

· Business – missing skills, process inefficiencies, missing information etc.
· Data – data placement, data quality, missing functionality etc.
· Applications – to be implemented, updated or removed
· Technologies – to be implemented, updated or removed

In performing the gap analysis, constraints (budget, time), dependencies, and readiness for change must be taken into account. After defining a high-level implementation strategy, major areas of work are translated into transition architectures.

The outputs of this phase are numerous and partly consist of updated version of artefacts produced so far such as the architecture definition document and architecture requirements specification. Other outputs include a report on the readiness for change of the organization, and the transition architecture which includes the consolidated gaps, dependencies, risks etcetera.

Best practices

Performing gap analysis is complex and time consuming. It is often underestimated with terrible consequences. Two main issues seem to cause this in practice:

· Dependencies are missed
· The readiness for change is too optimistic

In many cases, the latter is reinforced by the former as people tend to miss dependencies, push for a “favored (preferred?) solution” and suggest that implementing this favored solution is relatively easy. For example, we have seen cases where a “small change to a table and a form” turned out to result in a 4 month project with changes to at least a dozen systems and processes.

Building up an architecture repository with detailed knowledge about the organization is a key capability that helps organizations deal with gap analysis and impact assessment. It generally takes a while to gather this knowledge and storing and managing this information centrally will increasingly make life easier. In previous posts we already advocated the use of ArchiMate as a language and proposed to use a repository-based tool (such as BiZZdesign Architect).

Using a tool makes it relatively easy to find out which components / building blocks are relevant for impact assessment. Obviously, the segment under consideration may have changed, meaning that the architect must always confirm the validity of the models. A typical scenario would be to start with one building block (i.e., an IT system) and ask the tool to generate views that show which other building blocks are ‘attached’ to it. By also considering baseline and target plateaus, the below view can be arrived at

We have seen in practice that these diagrams work well for both validation (i.e., note that the customer file service is not realized by any infrastructure component presently, a clear omission by the architect!) and project planning.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Figuring out the baseline architecture and target architecture

2013-02-06T15:16:00.001+01:00

This is the fourth post in a series on TOGAF’s ADM. In this posting we zoom in on Phases B, C, and D, covering business architecture, information systems architecture, and technology/infrastructure architecture. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Introduction

The ADM’s phases B, C, and D cover what was traditionally thought of as “doing architecture”: modeling the architecture of an organization at some point in time. As such, these phases cover what was traditionally believed to be the main job of an architect: make architecture models (several years of consulting in the field of architecture have taught me that many clients still expect this of their architects). Given the fact that goals and steps for these three phases are so similar, I decided to cover them in one posting.

Objectives, steps, inputs and outputs.

The main objective of each of the B, C, and D phases is to develop baseline architecture and target architectures for each domain, and to perform a gap analysis between these two. Based on selected viewpoints, baseline and target architectures are documented in a way that the concerns of relevant stakeholders are addressed.

Even though it is acknowledged that a good architecture effort starts with a solid understanding of business architecture, it should be noted that the TOGAF standard is fairly IT-centric. Business architecture could be interpreted as “all things that are non-IT, but are relevant to IT”. In practice, though, we see more and more organizations to broaden the scope of business architecture.

The list of inputs for this phase is rather long. Key inputs are the organizational model for EA (explaining the organization of the architecture function), as well as the outputs of the previous phases, most notably the request/statement of architecture work and the architecture vision (a high-level, aspirational view of the end architecture product).

The steps that are conducted for each of the domains are relatively straight forward. Based on the architecture vision, a baseline and target architecture are developed and documented using relevant viewpoints. In many cases, reference models can be used in this activity (i.e., in telecom industry the eTOM, TAM, and SID standards are frequently used). A gap analysis for each individual domain is performed (optional), impact of the rest of the organization is analyzed, after which a formal stakeholder review is conducted. Approval is necessary to proceed with the next step.

The results of these phases are documented in the architecture definition document (ADD), possibly complemented by the architecture requirements specification (ARS). The main distinction between these two lies in the fact that the ADD has a focus on functional aspects whereas the ARS has a focus on non-functional / quality aspects. Both documents span all architectural domains.

Best practices

The phases under consideration rely heavily on TOGAF’s content meta-model which prescribes the concepts that can be used to model building blocks of the architecture:

Even though the core entities and some relations between them are defined, we noticed that in practice a more formal language improves communication drastically. This particularly holds for ArchiMate, another standard maintained by the Open Group. The core concepts of the ArchiMate language map well on the concepts prescribed by the TOGAF standard. An illustration of (part of the) meta model is given below:

The advantages of using a formal modeling language such as ArchiMate are manifold:

· Both concepts and relations between concepts are formally defined:

o Models are more easily interpreted

o It is easier to bring new architects on board

· The further development of the ArchiMate language is aimed at making sure the language covers all phases of TOGAF. This includes extensions for requirements, motivation, and project management

· Tool support – such as BiZZdesign Architect – is available:

o Automatically verify correct use (syntax) of the language

o Store architectural models as well as views for future reuse

o Reuse architectural knowledge across architectural teams using a repository

o Generate and manage different views on the same model for different stakeholders (isn’t this worth a separate bullet?)

We end this blog post with an ArchiMate diagram that shows the result of a gap analysis in the information systems domain, showing several applications which are to be phased out, as well as new functions being added to another system.

Outlook

Many best practices are to be mentioned for these phases, such as the merging the ADD and ARS documents, and the use of conceptual/ logical/ physical architectures. They will be covered in separate blog postings, not in this series. If you have thoughts or suggestions in this respect, please let us know!

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Starting an ADM cycle with a vision

2013-02-06T15:11:00.001+01:00

This is the third post in a series on TOGAF’s ADM. In this posting we zoom in on Phase A – Architecture vision. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Objectives, steps, inputs and outputs.

The official TOGAF 9 specification lists a wide range of objectives for phase A. All of these revolve around two things: developing a shared vision of where we want to go, and obtaining approval to move ahead. These goals reflect the fact that (most) architecture work in the context of the ADM has to do with controlled change in the enterprise.

Formally, this phase starts with the receipt of a request for architecture work from the sponsor in the organization which outlines such things as the strategy of the organization, business goals, high level description of what is to be achieved including time constraints etc. This document is a key source for deciding the scope of what is to be delivered down the road.

A key step in this phase consists of a stakeholder analysis which is essential in making sure that all the bases are covered. Doing this well will avoid a lot of issues down the road, as commitment and buy-in from key stakeholders tends to go a long way.

The definition / documentation of the vision itself may contain a first cut at a birds-eye view of the baseline and target architecture to be achieved by the current ADM cycle. At the very least, one must make sure that each of the domains (business, information systems, technology) are covered in this vision.

The vision is documented in the architecture vision document (a high-level, aspirational view of the end architecture product) and the statement of architecture work which complements the request for architecture work (the latter formally defines scope of the initiative). Therefore, this phase can be thought of as a “handshake” between the sponsor and the architecture team: a joint venture in making a request and promising to deliver on that request.

Best practices

There are several pitfalls in executing this phase that can easily be avoided. Keeping in mind that this phase is all about a “handshake” will prevent most of them.

First of all, it must be understood that this phase is executed in close co-operating between the sponsor and the architecture team. We have seen only too many situations where this phased was implemented as a “paper monster” in which many versions of request and statement are pushed around. To prevent this we propose to follow a workshop approach and merge the request and statement documents. This will both increase understanding and buy-in of all parties involved.

A second best practice in this phase pertains to documentation. More and more organizations use a formal architecture modeling language such as ArchiMate or a profiled-version of UML. Even though we strongly recommend using a formal modeling approach in conjunction with TOGAF, starting too early with modeling will only hinder the creative process.

The “best” approach depends on preferences within the group. However, in our experience a 3-step approach works best: (1) the key sponsor (frequently a single individual develops an idea and outlines it in half a page of text; (2) the architecture team facilitates a series of workshops in which the idea is further developed, using various brainstorming techniques and back-of-the-napkin style diagrams; (3) the end result is documented in high level diagrams in the formalized diagramming technique (preferably ArchiMate) adopted by the organization.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Preparing the organization for EA

2013-02-06T15:05:00.001+01:00

This is the second post in a series on TOGAF’s ADM. In this posting we zoom in on Phase P – the preliminary phase which prepares the organization for doing architecture with TOGAF. It may very well be that this is the most elusive phase of the ADM. We briefly present the objectives, inputs, steps and outputs of this phase after which we reflect on best practices for this phase.

Objectives, steps, inputs and outputs.

Formally the objectives of this phase include a review of the organizational context for enterprise architecture (EA), identifying sponsors and other stakeholders, ensuring that everyone who needs to be on board is actually on board, identify scope and the architecture footprint of the architecture initiative, verify alignment and define alignment with other frameworks and methodologies as well as define principles and select supporting tools. A whole list which, in short, boils down to preparing the organization for doing architecture work by tailoring the TOGAF framework.

The inputs of this phase can be split into non-architectural inputs and architectural inputs. The former are such things as board strategies, frameworks for project management and governance, budgets, IT strategy etcetera. These inputs entail the overall direction of the organization. Since it is rare to start from scratch (green field), architectural inputs include such things as existing organizational models for EA, existing frameworks, principles and repositories.

Given these goals and inputs, the idea is that the architecture capability – with the TOGAF standard in mind – gets to work in defining the scope of the enterprise, and to make sure the architecture capability is firmly embedded in the existing organization. This includes obtaining approvals and support.

There are several outputs of this phase which mainly mirror its goals. The most important output, however, is the request for architecture work which is usually sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle. This deliverable is one of the key inputs for the next phase – architecture vision – which is discussed in the next blog posting.

Best practices

In our experience, the preliminary phase is often underestimated in terms of importance and complexity. First of all, it should be noted that in doing architecture work: preparation is everything (note: the author of this post is a firm believer in rule #1 – be prepared!). Preparation means that people in the organization know what you are doing, and support the effort. Getting this right avoids the reputation of being an “ivory tower architect”.

Preparation also means that the right tools and means of support are in place. No carpenter would start on an important job without cleaning / sharpening his tools; nor should an enterprise architect embark on a mission critical to the organization without taking care of his tools including software, templates, methodologies etc.

The second aspect that was mentioned is complexity. We have encountered organizations where this phase was supposed to be completed in less than 2 days; the thought being “it’s all there in the book; all we have to do is delete the stuff we do not need”. In reality, however, there is a lot more to it. For example, at one large client we saw that executing the preliminary phase for the first time took close to three months (and involved a team of approximately a dozen architects), mainly because integration with existing frameworks was a lot more complex than anticipated.

In our experience, executing this phase should be a collaborative effort in which all the key players in the enterprise participate; from business to IT, from sponsor up to professional on the work floor. Therefore, we usually follow a workshop approach in which we interact a lot with people all over the organization.
Typical topics for workshops include the selection of inputs and outputs of phases, integrating the ADM with project management methodologies, or working on the content meta-model and standards information base.

Outlook

If you’d like to know more about our workshop cycle or the topics covered in this blog post, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Implementing & Using TOGAF: best practices

2013-02-06T15:02:00.000+01:00

Implementing & Using TOGAF: best practices

Architecture has been around since the mid 1980’s. The most famous standard from that era is probably John Zachman’s framework for enterprise architecture. Many more standards have been proposed since, ranging from the IEEE standard, DYA, DODAF/MODAF, TOGAF, ArchiMate, IAF etc. A good overview (in Dutch) can be found in the book Wegwijzer voor methoden bij enterprise-architectuur.

TOGAF

Architecture approaches focus on different aspects, such as architecture modeling or the process of doing architecture. TOGAF is an architecture framework that has 6 main components:

Some parts of the TOGAF standard are mandatory, whereas others are optional. This makes it possible for organizations to (to some extent) “cherry pick” and tune TOGAF for use in a wide range of organizations.

Overview of the series

This blog post is the first in a series on the Architecture Development Method. The goal of the series is to give a broad overview of the ADM, present best practices for using the ADM and to show how it can be adapted to your own organization. The topics to come are as follows:

· Preparing the organization for EA (Phase P)

· Starting an ADM cycle with a vision (Phase A)

· Figuring out the baseline architecture and target architecture (Phase B,C,D)

· Finding ways to implement the target architecture (Phase E)

· Translating opportunities to a well-defined project plan (Phase F)

· Managing implementation oversight of projects (Phase G)

· Dealing with change (Phase H)

· Covering the basics: keep track of requirements (Requirements Management)

This last blog post will also briefly discuss the relation between TOGAF and ArchiMate.

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment.

Using “back of the napkin” with TOGAF and ArchiMate

2012-02-01T17:28:00.003+01:00

Having recently read all of Dan Roam’s books (Back of the napkin, Unfolding the napkin, and Blah Blah Blah) I started drawing stuff whenever I could. I’m not naturally gifted at drawing (my kids tend to do a better job), but it was a whole lot of fun getting used to it again. I even got myself a nice “Wörther profil mechanical pencil” with very soft leads (6B) and carry that around all the time.

Having used my sketches in meetings, for helping my own thinking process, and helping clients solve problems I started wondering: how does this tie in with my enterprise architecture work? That is, how does it tie in with my two favorite open frameworks: TOGAF and ArchiMate? In this post, I’m exploring some ideas. I’ve included some drawings I made in the process (and following Dan’s rule nr 4 I didn’t clean ‘m up using PowerPoint). If you have any feedback at all: drop me a note and lets push this idea forward.

Groundwork

I realize that not all readers are familiar with TOGAF/ArchiMate or the Napkin-books. Here’s a crash-course with some links to further material.

First of all, TOGAF is an architecture framework, developed by the Open Group. Its main component is the Architecture Development Method (ADM). The ADM is a phased approach, that roughly works like this: after preparing the organization for doing architecture work (phase P), a vision is developed (phase A). In phases B, C, and D, a baseline architecture (how are we organized today) and target architecture (how should we be organized, relative to the vision we developed) are developed. Phase E is concerned with gap analysis, and finding ways to close that gap. In phase F a migration plan is developed. Phase G is concerned with helping and governing the implementation team implementing the vision by following the migration plan. Finally, phase H (not really a phase) is concerned with change management. The whole process leans heavily on a solid requirements management practice.

A second key component of TOGAF is the content metamodel. Many organizations opt to use ArchiMate, though, which is a more practical and graphical modeling language for enterprise architecture. ArchiMate is also an open standard that is maintained by the open group. Its core maps nicely to phases B, C, and D (baseline/ target architectures). The new motivation extension supports TOGAF’s preliminary and vision phase. Finally, the implementation and migration extension supports phases E, F, and G.

The formal specification of TOGAF can be found here, the formal specification of ArchiMate can be found here. More information on ArchiMate tooling, whitepapers etc. can also be found here.

The napkin-books start by explaining that the visual thinking toolkit consists of (a) the three built-in tools ‘hands, ‘eye, ‘minds eye’; (b) a simple 4-step process: look – see – imagine – show; (c) 6 ways of seeing, and (d) 5 aspects of showing, a.k.a. the SQVID.

For purposes of this post, (c) and (d) are most relevant. The former helps us ‘slow down’ and look at problems from different angles. The latter helps us generate more ideas with respect to an issue, by looking at it from different angles / aspects. These two are orthogonal, and jointly form a codex (A nicely formatted PDF version is available online for your reference).

The SQVID works like an equalizer: in some cases (i.e. for some people) we’ll want to draw simple – qualitative- visionary pictures focusing on the status quo, whereas for others we’ll want to dive in to elaborate, quantitative pictures that focus on the execution aspect in a future situation. By mapping these onto the 6 ways of seeing, we’ll get a pretty good idea of what kind of picture may work best in any given situation.

Mapping

So far so good. Now how do these two tie in together? To answer that, I’ll run through a typical example of TOGAF’s ADM. Bear in mind that TOGAF incorporates many good/best practices, and has predefined steps, inputs, and outputs for each phase, relying on its content metamodel (or ArchiMate) for their content.

Phase A

In phase A of the ADM, the focus is entirely on vision. In this phase, key stakeholders (at least a sponsor) and architects sit down to figure out what it is exactly that we want to achieve. One of the things that result from this phase is an Architecture Vision document which contains a “Solution Concept Diagram”. The official TOGAF 9.1 spec even says that “…the solution concept represents a "pencil sketch" of the expected solution…”. Not a bad start for linking to the napkin-approach.

I think the codex actually helps a lot in figuring out the vision, and getting a clear, shared understanding. Since we’re mostly talking to business folk and sponsors, the equalizers of the SQVID should probably be on “simple – qualitative – vision”. Even more, the diagram should probably cover “what” and “where” at a minimum (we’ll figure out the “how” and “when” later). However, the “how much” shouldn’t be forgotten as we probably also have a business case to write…

What about ArchiMate? First of all, I do think that it is possible to draw simple – qualitative – visionary ArchiMate diagrams. However, I’m getting more and more convinced that this should be done after we obtain agreement of what the vision is that we’re trying to implement. In other words, we should translate the simple napkin-style diagram to a simple ArchiMate diagram. The former we can keep as a means of communication, whereas the latter is the basis for starting more elaborate analysis in subsequent phases

Phase B-C-D

In phases B, C, and D the focus shifts to modeling baseline and target architecture for the 3 domains of TOGAF: business, application, and technology (Note: some claim that this layering is fundamentally flawed because everything that is non-technology is stuck in business. This may or may not be true. Fact is that many organizations successfully use TOGAF’s ADM to drive their architecture practice and add value to the business. I strongly believe that the idea of using baseline/target architectures is solid).

The audience in this phases changes somewhat: architects are still involved, and usually work closely with process managers, information managers, and IT-staff to figure out where we are now, and where we want to be relative to the vision that was articulated. This changes the setting of our SQVID equalizer, probably to “elaborate, qualitative, execution, individual”. I’ve deliberately used ‘individual’ here; in practice, gap analysis often pushed to phase E. As for the diagram type, “who/what”, as well as “where” and “how” are probably most useful. We may also need some “how many” charts, for example to map out expected change in throughput of processes, volume of data storage, number of business transactions and so on.

This is where the strength of ArchiMate really comes in: it provides a strong and elaborate vocabulary to map out the baseline/ target architecture of the enterprise. It is not a hard language to learn, but still: for we need all our thinking and processing capacity to get this right. It may therefore be a good idea to brainstorm using napkin-style drawings, and translate them to formal ArchiMate diagrams. The ArchiMate models of this phase should be linked to the one resulting from phase A for tracking/tracing purposes, giving us the confidence to push forward.

Phase E-F

In phases E and F the focus shifts again: this time we’re figuring out how much work we actually have to do (i.e., the delta between baseline and target architectures à D), and how we’re going to solve this with a solid migration plan. Various stakeholders are involved here, so we’ll need lots of (different, but linked) diagram types.

For example, we’re talking to project management here (definitely a ‘when’ type of diagram of the “elaborate – execution – change” type. We’re also communicating this with business stakeholders and sponsors on timing (“when”, but probably of the “simple – change” type), cost/benefit (how many) and so on. Our technical staff is also still involved, as their expertise is needed to formulate a valid and viable plan!

Again, napkin-style diagrams and sketches should be a useful for brainstorming and developing ideas: we want to ‘see’ the ideas develop and grow as we work with various stakeholders. Integrating these results in formal ArchiMate diagrams will validate the ideas: modern tools such as BiZZdesign Architect have many capabilities for roadmapping, impact analysis, consistency checks, and visualizations. Saving these models will also build a solid architectural knowledge base that may be re-used down the road in subsequent ADM cycles.

Summary & Conclusions

In this post I brainstormed and presented some initial ideas with respect to combining the visual codex from the back of the napkin work with enterprise architecture work using TOGAF and ArchiMate. I think / hope the following picture says it all: I believe that combining both will help architects (be victorious by) deliver(ing) value in their organizations.

If you’d like to know more, please contact me directly at b.vangils@bizzdesign.com or leave a comment!

How issues with sewer resemble enterprise architecture problems

2011-12-16T09:49:00.001+01:00

Every now and then I run into trouble with "shared infrastructure" in the real world that resembles my work so much that it would be silly not to write about it. Today it happened again with a clogged sewer line and a service that we have to declog when necessary. See the following diagram for an illustration

The pink/orange block depitcs a row of houses with numbers 1 to 5. The blue blocks are the front yards of each of the houses. When designing these houses in the 1940, a cost saving measure was taken by building a shared infrastructure for sewer lines. The green lines show the sewer lines, the squares are "declogging points", points where the sewer has a small lid where it can be inspected and declogged. The 5 houses have this shared infrastructure with a single access point to the shared main sewer line owned by the city.

Lets assume that I'm living on number 3. This morning I found out the hard way that something was wrong. It could barely be inside the house, as we recently replaces all pipes. Running out and checking the first inspection point showed that the line (indicated in dark red in the diagram) was clogged. This is where it gets interesting.

Years ago we bought a subscription to a declogging service. Paying a small fee per month, these guys are supposed to declog up to the point where the main sewer line is entered. In our case, that's 2 doors down where Street A and Street B intersect. Ouch. That contract doesn't provide for such a circumstance! Time to revisit the architecture of our sewer solution (i.e., consider a dedicated solution, or fix the contract!)

The parallell with enterprise architecture seems obvious. Many organizations make use of some sort of shared services on infrastructure... and run into all sorts of problems. Perhaps I should use this example in training settings!

Finding use for useless words

2011-07-15T03:34:00.001+02:00

I am currently working on an assignment at a client that involves cleaning up an architecture standards base. A series of postings on this topic are due some other time. In the context of this engagement, I found that typical "useless" or "vague" words suddenly become very useful. Let me elaborate.

First of all, we had to find a term for standard components, models, etc. that people use in doing their work. Half jokingly, we started calling them "things". Turns out that the term "standard thing" took off and was actually just vague enough to denote exactly what we wanted. In the past I've used terms such as "standard asset" but somehow that just sounds too formal.

A typical use of the term standard is that of a constraint; a rule that has to be enforced on the "thing" we're building (in the case this engagement: IT systems). This gave us the distinction between "standard thigns" and "standards about things".

Confusing? Perhaps, but it seems to work in practice. And while on the topic of terminlogy, there's another good one to consider. At some point we needed a generic term to denote "anything vaguely technical". One member of our team suggested the word "stuff" for this, and guess what: it stuck!

Social architecture

2011-04-07T21:43:00.002+02:00

As more and more people busy themselves with architecture, discussion around this discipline seem to go around in cirles. Talking to practitioners, it seems that we all have experienced more than once discussions around questionssuch as

What is architecture really?
How should we document architecture?
What does it mean to do architecture?
Who do we do architecture for?
etc.

Even though these questions are interesting from an academic perspective (and yes, I'm actively pursuing this line of research), in pracctice we just have to get the job done!

It appears that traditionally, architecture is concisered to be an engineering discipline: we figure out what it is we want to achieve, what the gap is between where we want to go and where we are, make a plan, and implement it in the organization. These days, however, more and more people with a non-engineering / IT backbground are involved in architecture work, leading to renewed attention to disciplines such as

business architecture
strategic architecture
social architecture
etc.

Different people with different backgrounds getting involved in this field, implies that the way we consider orgazations shifts too (probably from a "machine perspective" to a "social perspective", see e.g. images of organization). It follows that the way the fundamental questions raised previously deserve different answers too.

I am partiularly interested in the impact that this shift has on the question of how to do architecture, as well as the role of architecture models. My hypothesis is as follows: in a social perspective of organizations, doing architecture means influencing the people that make an organiztion to move in a certain direction which can be clarified by architecture models.

This post is an open invitation for all readers to share their thoughts, experiences, and best practices with respect to the above hypothesis.

(e)Books

2011-02-12T10:47:00.014+01:00

Introduction

When mankind invented writing, it changed the world. Keeping track of natural events, planning crops and harvests, tracking commerce, history, it all became possible when we started writing. Similarly, it is often said that the invention of the printing press brought about one of the biggest changes in the history of mankind, since this made it possible to make texts available to the grand public: printing religious texts, scientific text and – when printing became more wide spread and thus cheap – also news, novels, poetry et cetera.

When more and more texts became available, new issues had to be resolved. The great library of Alexandria may have been big in its day, it is nothing compared to what modern day libraries have stored. A personal favorite is the beautiful public library on 5th avenue and W42nd Street in New York, USA. Having so much information at hand creates the need for better ways to store, preserve, and index materials leading to such fine things as the dewey decimal system and full-text search based on the tf.idf family of weights. Full-text search became even more important with the rise of the Web which can be seen as a whole new way of distributing information (some more background of that can be found in my dissertation. See my publication page for details).

With the rise of the Web, the adage “information wants to be free” got a whole new meaning. Indeed, many texts are available for free on e.g. google books and the Gutenberg project. There is, however, still a big market for paid content: books, magazines etc. Interestingly, the biggest threat for book selling companies may not be the free content available on the Web itself, but the developments around e-book which are all about distributing content cheaply and digitally without the need of sending a paper copy of a book over such old fashioned media as the postal company or UPS!

Several players, including Amazon, realized early on that e-books are here to stay and took the challenge head-on. Amazon successfully introduced the kindle e-reader. Interesting questions in this respect are: how big is the impact of e-books on (the architecture) of companies in the book-business, and what changes for customers?

Market analysis

Typical market analysis uses Porter’s 5 forces model, possibly combined with the 4 PEST-factors. The introduction of e-books as a way of getting access to content changed the market drastically, changing the market definition from buying books to a market for content, with segments for the way this content is delivered: paper, or digitally. Further segmentation can be based on such things as types of content (i.e., art or “just letters”) or price.

It is not hard to imagine that – similar to physical book distribution – economies of scale apply here as well. Having a large piece of the e-book market makes it easier to maintain a good distribution network. Companies such as Amazon (with no physical stores) tried to gain competitive advantage by offering a complement product: the e-reader (kindle) with integrated access to their stores and automatic synchronisation of bought materials with devices. Other online sellers of e-books (e.g. the Dutch bol.com site) do not have this advantage.

The technological innovations partially provide the key to understanding why Amazon is so successful. Cheaper access to certain types of content, large / diverse supply, and instant delivery goes only so far. In my view, Amazon’s competitive advantage stems in no small part on the fact that they approached reading as an experience. Their business model is based on:

A relatively cheap device with easy to use interface and excellent functionality for bookmarking, note keeping etc.
Clients in hardware form (the kindle) and software form (apps for tablets, smart phones and computers)
An integrated approach involving Amazon’s store; a personal account with sufficient storage capacity for your materials; excellent delivery channels and automatic delivery to devices and clients

Of course there are also challenges to overcome. Barnes and Noble – which is not a pure webshop but also has a chain of very nice bricks and mortar bookstores throughout the us – also offers its own e-reader: the nook. In contrast to Amazon’s device, the nook has a color screen and offers functionality to loan books to friends, something that Amazon doesn’t have just yet.

In the e-reader market, competition comes mainly from rivals such as Sony (with an excellent e-reader) and the introduction of the tablet computer (such as the Samsung Tab and the iPad) it was predicted that sales of e-readers would drop. Given the loose coupling principle that Amazon applied, this may be a threat to its e-reader business. For book-sales, however, this is not the case as software based clients for these tablet devices are readily available.

As the big boys are fighting and start their technology race, it is the consumer who benefits!

Consumer perspective

I confess to being somewhat old fashioned. I write using a fountain pen (green ink!), prefer vinyl over CD’s, and enjoy my old film-based SLR camera. It’s no big surprise that I enjoy my physical, paper books as well. Nothing beats picking up an old book that I inherited from my grandfather and reading the letter from his old soldier buddies that he put in there. Lots of sentiment there.

However, being a father of two I sometimes have to be practical too. Collecting books (and music and … other stuff) eats up a lot of space. Not so long ago, I therefore thought I’d give the kindle a chance. I was in for quite a surprise, as this really rocked my world: reading experience is awesome, ease of ordering materials is dangerously easy and supply is growing at a dazzling pace. Still waiting for the Dutch newspaper to be available, but other than that I am (to quote a marine buddy of mine) as happy as a pig in shit.

Personally I don’t miss the color view of the nook, and since I use the device mainly for reading I won’t even consider a tablet pc. The race is on, though, and more features that make life easier for consumers are to be expected in the next few years. Let’s see if the big boys such as Amazon manage to stay ahead of the pack!

Architecture

From an architecture perspective, the addition of e-books and paraphernalia (kindle etc.) is interesting as well. The following figure illustrates part of the architecture of Amazon. Note that I have to make assumptions / guess here and there as I have never been at Amazon to discuss this (unfortunately! Invitations are more than welcome!).

In describing the architecture I adopt a business function perspective, firstly focussing on the outbound logistics part. Models are of course made in ArchiMate. For physical goods, Amazon already had arrangements. Physical goods are shipped throughout the world using the services of a third party such as UPS or FedEx. For digital goods (e-books), something new has to be arranged.

More on the delivery functions follows. Staying in the business layer of ArchiMate for a bit, the sales-functions are also interesting to consider:

The order goods business service was at first only accessible via the webshop channel (business interface). However, with the arrival of kindle, a new channel has to be added. The kindle-shop (which resembles the webshop but is directly accessible via the kindle device and therefore optimized for a smooth experience) is new.

IT-support is also interesting, especially since the “kindle shop” is pretty much all IT. There are several ways to go about modelling this: either by staying in the behaviour column or the structure column of the ArchiMate metamodel. The following example combines these two from the process perspective

Here we see that the e-book ordering service (part of the e-books product) is a specialization of the order goods business services. The order handling process uses four application services which are realized by several systems. As Amazon also offers access to materials from third parties, links to (the interfaces of) external systems have to be taken into account as well. This also goes for payment handling which is typically done by credit card companies. Not that the diagram doesn’t use a roadmap view. It is obvious, however, at the e-book management system is new and most of the rest of the system is already available.

Actual delivery requires some tricks. Devices and network connections are modelled at the infrastructure layer:

This (partial) diagram shows part of the reason why Amazon’s kindle is such a success. It shows the integrated approach that Amazon uses for its kindle store. On the one hand, the kindle store is assigned to several business services (such as ordering of e-books). On the other hand, it also shows that the kindle store has an integrated delivery mechanism that ties directly to the kindle device. That is, delivery of e-books to the kindle does not require plugging the device into the computer and manually installing the e-book on the kindle device.

Finally, it should be noted that there is a lot more to be said about this cas:

Note the WWW connection in the last diagram. The system is setup in such a way that the kindle device uses a wifi-connection if available. Some models of the kindle use a built-in 3g connection as a fall-back mechanism to be able to shop if no wifi-connection is available.
Note that in the architecture discussion we spoke only about the kindle device. There is, however, also a kindle client that can be installed on other devices such as the iPad, the Samsung tab, a pc or even smart phones. By using loose-coupling, these clients can tie in directly to the kindle-store as well as the delivery mechanism.

Abstract and concrete architectures

2010-12-03T09:08:00.009+01:00

Introduction

The topic of “abstract” vs “concrete” architecture seems increasingly popular, especially in relation to the ArchiMate language. Recently this topic came up in consulting assignments, teaching settings, and the linkedIn group for ArchiMate. In a previous posting I briefly touched upon this topic when I wrote about the combining the specialization relation and the aggregation relation to create a plug-and-play process architecture. In this posting I will re-examine this topic. The proposed solution has been tried and tested and is now used in several organizations.

The issue

The issue to be solved is fairly straight forward. In architecture modeling, two approaches can be followed: (a) an architecture model is very close to the physical world and attempts to represent all the `things’ in it one-on-one, albeit at a high level of abstraction, or (b) an architecture model abstracts from reality as much as possible and only represents `patterns’ of (interactions between) `things’ in the real world. The former is frequently referred to as a conceptual or abstract architecture, whereas the latter is often referred to as a physical or concrete architecture.

Many architecture approaches, including e.g. Capgemini’s Integrated Architecture Framework and TOGAF distinguish between conceptual, logical, and physical architectures. Conceptual and logical are abstract, whereas the physical architecture is concrete. The ArchiMate language does not distinguish between these levels, even though it is often claimed that behavioral concepts (services, functions, processes) are abstract and active structure elements (actors, roles, application components) are concrete.

Both abstract and concrete architecture models can be very useful and the question is how to combine them in a single model to get the best of both worlds. The underlying assumption is that ArchiMate – an open industry standard – language is used.

The solution

The basic observation underlying the solution proposed in this blog post is this: at the abstract level we identify the type of things we wish to talk about, whereas in at the concrete level, we identify their manifestations in the real world. For example, at the abstract level we want to talk about ERP software that supports people in performing their work. At the physical level, however, we want to talk about the fact that location A uses an ERP implementation from one vendor, whereas location B uses an ERP implementation from a different vendor, for performing the same kind of tasks (i.e., in a similar process).

The ArchiMate relation that is closest in semantics is the specialization relation which can is defined formally as “The specialization relationship indicates that an object is a specialization of another object”. This relation is mostly used for type/instance relations and is well known in many langauges including UML, Object Role Modeling etc. In this case we use it to denote that an abstract model element may have different concrete manifestations.

Example 1: component types and instantiations

The first example diagram illustrates the situation outlined in the previous section. At the abstract level, life is relatively simple; all that is to be modeled is the fact that for the process named Hotel reservation (be it at the front desk, or online) uses two application services that are realized by an ERP component:

At the physical level, we wish to denote that two ERP implementations exist and that branch offices (modeled using the Actor concept, see e.g., this posting) uses these different implementations. The following figure shows how this can be represented:

A big advantage of this approach is the fact that the specialized (concrete/ installed) versions of the ERP package inherit all aspects of the abstract ERP component. I.e., the two application services are inherited and need not be modeled again. Similarly, use of infrastructure services, access to data etc. is all modeled only once. This allows one to create an Amsterdam-specific image which could look something along the lines of:

Note that this mechanism should not be used to represent that we have two ERP packages by two different vendor platforms. Vendor platforms, such as SAP or PeopleSoft are usually modeled using the System Software concept.

Example 2: domesticated applications

Another interesting example of this mechanism showed up when discussing the use of the domestication (thanks for sharing this Ronald, Magchiel !).

The example case starts with the definition of a domesticated application. This was defined by the group as an application that uses federated authentication services as well as group service using some standards (modeled using the principle concept in BiZZdesign architect). It was recognized that domesticated applications can be accessed (suggesting the Application Interface concept) using OpenSocialGadgets. These gadgets are used in a portal environment that is called EduSocialPortal. The abstract architecture therefore can be modeled as follows:

Again, the specialization mechanism is used to cross the bridge to the more concrete/physical level. Specific domesticated applications (i.e., Alfresco) deliver services (document management) that can be accessed via gadgets and are made available in a specific EduSocialPortal (Coin demo portal):

Again, the inheritance mechanism ensures that the proper application functions with underlying infrastructure services are used.

Final remarks

The specialization concept is a powerful one and can allows for a straight forward way of modeling at two levels of abstraction. As is so often the case: this comes at a cost as both levels as well as the links between them have to be managed and kept up to date. Even more, when generating views in an architecture tool, the modeler should be very aware that concepts of two levels of abstraction may be combined in a single view. I highly recommend adding a profile (i.e., “stereo typing”) concepts from the conceptual layer so that they can be easily recognized using a color-view.

Modeling locations with Actors in ArchiMate

2010-11-17T15:57:00.007+01:00

One of the issues that we bump into often is the question how to model a location in ArchiMate. Recently there was a long and interesting thread about this subject on the LinkedIn group for ArchiMate for example. Several options were suggested, including a suggestion that the ArchiMate language should be extended. In this blog post, I will set out my "solution" to the problem, as well as point out some issues with it.

First of all, note that the ArchiMate metamodel has three layers: business, information, technology. In this respect, it seems that location fits best in the business layer even though it can be argued that a node in a network can also be considered a location... For this post, I'll stick to the business layer. Even more, there are three columns. active structure, behavior, passive structure. Active structure concepts are able to beform behavior. Passive structure concepts undergo behavior. In my opinion, location doesn't naturally fit either, but I'm willing to accept the argument that an active structure concept fits best based on the fact that "in a location, certain behavior takes place". In my view, then, the best concept for location comes from the active structure part of the business layer and thus I select the Actor concept.

A simple example shows how this works. Assume that we are modeling a firm that develops tools and does consulting to support those tools. The company is based in two locations: Netherlands and Belgium. Typical behavior at a high level is modeled using Business Functions as these provide a nice stable basis for further develompent.

In this view, a labelview was applied to denote business processes that belong to certain business functions. It is easy enough to combine these processes into an "end to end" process for further analysis. For example, lets say we're launching a phone campaign to promote a new tool release where we offer clients advice (upgrade or not?), and do the actual deployment. Here's the diagram:

So far so good. Modeling becomes more interesting when realizing that the Actor concept is also used for other purposes. Most notably, the actor role is also used to denote who performs a certain role as illustrated in the following diagram

Here we see two things. On the one hand, the color view depicts that certain parts of the new campain can only be performed in the Netherlands whereas other parts can be executed in both countries. Another aspect that is visualized here is that the phone campaign is performed by a call center which can either be done by people from an external department or by people from the consulting department. The other parts of the process can all be done by someone from the consulting department.

Note that the Actor concept is used for two different "things" here. This works relatively well and in my opinion no new ArchiMate concept is required at all. It does seem that new ArchiMate users/readers might be confused by this double interpretation of a single concept. Therefore, some care should be taken to make sure that everyone is on the same page (i.e., by developing clear modeling guidelines). Also note that modern ArchiMate tools such as BiZZdesign architect have the option of using a profile to further stereotype model concepts which helps in analysis, visualization and communication with different groups of stakeholders.

Living 2.0

2010-10-10T12:00:00.003+02:00

It appears that the concept of "work 2.0" or "the new way of working" (NWOW) is still quite popular as the subject is actively being discussed in many blogs, books, fora, etc. Fact of the matter is that the title / label seems completely wrong for the topic, possibly due to the fact that many companies just don't get it.

It is hard to come up with a very strict definition of what the 2.0 concept really is, or entails for companies. I'll stick to mentioning some of its aspects here to get a sense of the spectrum.

One of the best one-word characterizations of "2.0" seems to be 'social': sharing knowledge & information in and with a group of people of which not all members are necessarily known. It even goes as far as sharing belief systems and relations (a rather extrem version of 'any friend of yours is a friend of mine'). Perhaps the most prominent/ visible aspect of the 2.0 movement is the digital aspect of it. Indeed, social media such as twitter, facebook and hyves are important enablers in this respect. Many companies are struggling with these technologies indeed. The discussion tends to focus on productivity: does technology xyz enable my workers to be more productive? Indeed, employees tend to be considered as 'production units' and the new tools and techniques as 'toys to keep the kids happy'.

In the workspace, the new way of working is often equated to "no longer work from 0900-1700, but enable the workforce to work whenever they want. In itself this could be a good thing. It recognizes that a nine to five mentality no longer fits our needs. Unfortunately it seems that many companies again take a productivity approach: because n% of my workforce is in heavy traffic while commuting into work, we'll allow for more flexible work hours so they can get some work done before they hit the road. The consequence, company hands out laptops and cellphones for mobile connectivity and pride themselves on how well they facilitate their workforce.

Don't get me wrong: I'm not against mobile working, handing out laptops, cellphones and flexible work hours (on the contrary!). My point is, that looking at these phenomena in a 2.0 context, the line of reasoning does not make sense, even though some of the consequences of this line of reasoning do!

In my opinion, the 2.0 concept is about the following things:

empowerment of people
work = fun && fun = work (or: fading boundaries between work and private life)
focus on relations with people rather than a focus to the company / brand

Indeed, new "toys" (laptops, cell phones, instant messaging, ..) can empower people. When taking a 2.0 approach, however, companies should put the people first and dare to be bold. Let the workforce figure out what they want, why they want it, and trust that this will motivate them enough to do the right thing and make the company thrive!

I'll give two small examples of what this could entail. Lets start with my own personal experience as consultant / trainer. Over the last few weeks I have kept of how I spend my time. I've learned that I'm on the move (taking trains, airplanes etc.) for 15-20% of my time. During this time, I want to busy myself with things I think are fun: writing blogs, conversing with clients, working on client reports, reading (summaries of) new technology books online, skyping with the kids etc. First thing to note: for me there is no boundary between work and private life. I do a lot of "stuff" during the week and for part of this "stuff" (expressed in 'hours') I happen to get payed. Second thing to note: in order to do the things I want to be doing, I need two things: devices & connectivity that enable me to get my hands on computing power and connectivity to my loved ones.

The former is sort of taken care of: I have a company-provided laptop that mostly does the job. It is a bit slow, too big, and too heavy to carry around all the time, but at least it is there. It would help if the concept of mobile working (mobile not being: working at home in the morning, dumping laptop in the back of the car and driving into the office) was thoroughly understood for our company. The bigger issue, however, is connectivity. Here's economics at work for you: the Netherlands has pretty good connectivity in most of the country. Then why is it that, while taking a train from A to B, I lose my connection so often? Even for up to 20 minutes at a time? Why do we pay so much for this lousy service? Even while typing this piece, my provider dropped the connection at least 3 times...

From a social / 2.0 perspective I can't help but wonder if no one at the provider is empowered enough to take bold action and actually fix this. From a strategic perspective, this must make sense! many consultants are out there every day, and I'm sure they're willing to pay a (slight) premium for a guaranteed connection...

All in all, I propose we drop the label "the new way of working" and start talking about "living 2.0". Working should be a way of life! Working is fun, and it is fun to work. We just happen to have made a deal with a company full of interesting people with shared interests, and they pay us to do what we think is fun in the first place!

	Title: enterprise architecture at work ISBN: 978-3-642-01309-6 This is the book where it all started, at least for me personally. I guess I could say that “I was there when they wrote the book” as I was working at Radboud University at the time. Since this book has been published, I’ve had the pleasure of meeting most of the authors in person. Since then, the second edition of the book has been published. If you want to know more about architecture in general, and the philosophy and power behind ArchiMate, then this is the book to read!
	Title: ArchiMate 2.0 specification ISBN: 9789087539474 Title: TOGAF 9.1 specification ISBN: 9789087536794 There is a lot of synergy between the ArchiMate and TOGAF standards which makes them a powerful combination in practice. The fact these are open standards only make them more appealing to me. Pragmatic standards that add a lot of value to the architecture practice of many organizations world-wide.
	Title: The back of the napkin ISBN: 1591841992 Title: Blah blah blah ISBN: 1591844592 The latest addition to my collection. I can’t believe I didn’t take the time to read these sooner. Two great books by Dan Roam on solving complex problems with simple pictures. I’ve used the ideas from these books in practice and found them very practical and useful. Great way to find solutions to complex problems and to build a shared understanding. I am combining these pictures with TOGAF and ArchiMate!
	Title: Strategy synthesis ISBN: 1408018993 A no-nonsense book that demystifies the field of strategic management. 10 strategic themes (competitive advance being but one of them) form the basis for this book. The two most extreme (diametrically opposed) perspectives on each of the themes are discussed and grounded in literature, leaving it up to the practitioner to find a solid synthesis for the dilemma’s in practical situations. Great book, easy to read!
	Title: Business Model Generation ISBN: 0470876417 A must-read for anyone in business. The business model canvas provides a structured way of documenting business models. A business model can be seen as the result of the strategic management process, and describes the essence of what an organization should do in order to be successful. Finally a structured model-based approach to link strategic management to enterprise architecture!
	Title: Enterprise Architecture as Strategy ISBN: 1591398398 Title: IT Governance ISBN: 1591392535 Two books, two topics, but with the same authors. In my mind, both go together, the one building on the work of the other. What I like about these books is the no-nonse, enterprise-focused, framework-neutral coverage of strategic themes in relation to architecture and governance. In my mind, the business model canvas (from the business model generation book) focuses on the question what an organization should do to be successful, and these books zoom in on strategies to make that happen with a solid architecture + governance practice.
	Title: Polarity management ISBN: 0874251761 I have found that many ‘problems’ in organizations are seen as either trade-offs, either-or problems and so on. Fact of the matter is that many issues are polarities and trying to solve them with traditional one-off decisions will only get you in trouble. Barry Johnson introduced a useful technique for handling these “and-and” problems called polarities. Easy read, very practical.
	Title: Game storming ISBN: 0596804172 The nature of work in the post-industrial era is completely different from what we’ve been used to so far (i.e., Taylorism). This book looks at the world of business in terms of serious games. Some of these games are quite useful in practice. Recommended for inspiration on both a different way of thinking, and for organizing all sorts of workshops.
	Title: the two cultures ISBN: 0521457300 A classic! This philosophic book gives insight in the question how to deal with groups of people with opposing worldviews. Useful for architects as we frequently work with people with an engineering / mechanistic worldview as well as people with a more open/ organic worldview.

Strategic Architecture

Architecture standards: Wrap-up and summary

Architecture standards, why again?

An overview of best practices

Common vocabulary

A clear structure

Documentation

Top-down, Bottom-up

Managing the life cycle

Making architecture standards work

Summary

Architecture standards: Governance

Introduction

Keeping the standards body up to date

Standards use

Getting started

Architecture standards: Life cycle

Introduction

Life cycle

Process and templates

Architecture standards: Embedding

Top-down, bottom-up

Alignment

Approach

Architecture standards: Documentation

Using standards in architecture work

Requirements for standards documentation

Document management

Architecture standards: Terminology

The term “standard”

Deck of cards principle

Rules and Components

Examples

Architecture standards: intro and overview

Why architecture standards?

How do architecture standards realize business value?

How to use standards

Overview blog series

Covering the basics: keep track of requirements

Objectives, steps, inputs and outputs

Best practices

TOGAF and ArchiMate integration

Questions

Dealing with change

Objectives, steps, inputs and outputs

Best practices

Outlook

Managing implementation oversight of projects

Objectives, steps, inputs and outputs

Best practices

Outlook

Translating opportunities to a well-defined project plan

Objectives, steps, inputs and outputs

Best practices

Outlook

Finding ways to implement the target architecture

Objectives, steps, inputs and outputs.

Best practices

Outlook

Figuring out the baseline architecture and target architecture

Introduction

Objectives, steps, inputs and outputs.

Best practices

Outlook

Starting an ADM cycle with a vision

Objectives, steps, inputs and outputs.

Best practices

Outlook

Preparing the organization for EA

Objectives, steps, inputs and outputs.

Best practices

Outlook

Implementing & Using TOGAF: best practices

Implementing & Using TOGAF: best practices

TOGAF

Overview of the series

Outlook

recommended reading

Using “back of the napkin” with TOGAF and ArchiMate

Groundwork