Strategic Architecture

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!

Architecture standards: Documentation (3/7)

2012-01-24T14:44:00.002+01:00

This is a crosspost from the BiZZdesign blog. If you have any comments, please leave them there!

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.

Outlook

If you’d like to know more, please contact the authors directly at b.vangils@bizzdesign.com / s.vandijk@bizzdesign.com or leave a comment. The next post in this series covers the embedding of standards. It is scheduled to be posted on the 6^th of February.

Architecture standards: Terminology (2/7)

2012-01-10T08:01:00.000+01:00

This is a crosspost from the BiZZdesign blog. If you have any comments, please leave them there!

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:

o Rule: All solutions and applications should comply with the enterprise security standards such as identity management, access management, auditing and monitoring, and information control.

o Details of each of the security domains mentioned could be documented in separate specifications.

o 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.

o 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:

o 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.

o Details and specifics of how the interfaces should be defined can be documented in separate specifications.

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

Outlook

If you’d like to know more, please contact the authors directly at b.vangils@bizzdesign.com/ s.vandijk@bizzdesign.com, or leave a comment. The next post in this series covers thedocumentation of standards – a topic that was briefly touched upon already in this posting. It is scheduled to be posted on the 23^rd of January 2012.

Architecture standards: intro and overview (1/7)

2011-12-22T07:58:00.002+01:00

This is a crosspost from the BiZZdesign blog. If you have any comments, plesae leave them there!

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.

Outlook

If you’d like to know more, please contact the authors directly at b.vangils@bizzdesign.com/ s.vandijk@bizzdesign.com, or leave a comment. The next post in this series covers the introduction of a common terminology to use within a standards practice, and will also include suggestions and examples. It is scheduled to be posted on the 9^th of January 2012.

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!

TOGAF series 9/9: Covering the basics: keep track of requirements

2011-12-16T09:00:00.003+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 andimplementation & 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.

TOGAF series 8/9: Dealing with change

2011-11-28T17:48:00.001+01:00

This posting is the sixth in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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:

1. Registration of all events that may impact the architecture
2. Resource allocation and management for architecture tasks
3. The process or role responsible for architecture resources has to make assessment of what should be done
4. 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. The final post in this series entitled “Covering the basics: keep track of requirements” is scheduled to be posted on Monday the 12^th of December.

TOGAF series 7/9: Managing implementation oversight of projects

2011-11-14T13:31:00.001+01:00

This posting is the sixth in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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 they got it 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 jamstates 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. The next post in this series entitled “Dealing with change” is scheduled to be posted on the 28^th of November 2011.

TOGAF series 6/9: Translating opportunities to a well-defined project plan

2011-11-01T09:37:00.003+01:00

This posting is the sixth in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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 form 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. The next post in this series entitled "Managing implementation oversight of projects" is scheduled to be posted on the 14th of November 2011.

TOGAF series 5/9: Finding ways to implement the target architecture

2011-10-17T15:15:00.001+02:00

This posting is the fifth in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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 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. The next post in this series entitled “Translating opportunities to a well-defined project plan” is scheduled to be posted on the 31^stof October.

TOGAF series 4/9: Figuring out the baseline architecture and target architecture

2011-10-03T11:08:00.000+02:00

This posting is the fourth in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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

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. The next post in this series entitled “Finding ways to implement the target architecture” is scheduled to be posted on the 17th of October 2011.

TOGAF series 3/9: Starting an ADM cycle with a vision

2011-09-19T15:02:00.000+02:00

This posting is the third in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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 therequest 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 requestand 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 developed further, using various brainstorming techniques and back-of-the-napkin styled 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. The next post in this series entitled “Figuring out the baseline architecture and target architecture” is scheduled to be posted on the 3^rd of October 2011.

TOGAF series 2/9: Preparing the organization for EA

2011-09-05T09:44:00.001+02:00

This posting is the first in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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 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 model 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 standing 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 venture on a mission critical to the organization without taking care his tools which include 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 down to professional on the work floor. Therefore, we usually follow a work-shop approach in which we get to 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 blogpost, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment. The next post in this series entitled “Starting an ADM cycle with a vision” is scheduled to be posted on the 19th of september.

TOGAF series 1/9: Implementing & Using TOGAF: best practices

2011-08-22T14:40:00.000+02:00

This posting is the first in a series. It is cross posted to from the BiZZdesign blog. In case you have comments: please post them on the BiZZdesign blog site

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 bookWegwijzer 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)

Outlook

If you’d like to know more, please contact the author directly at b.vangils@bizzdesign.nl, or leave a comment. The next post in this series entitled “Preparing the organization for EA” is scheduled to be posted on the 5^th of September.

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!

Explaining principles, and making them work

2010-09-09T19:49:00.009+02:00

Over the last few years, many different definitions of the concept of enterprise architecture have been proposed. However, rather than focusing on definitions, the focus should be on what we can achieve by adopting architecture methods. Once we know the goals of architecture initiatives, communication/ documentation as well as the process aspects follow naturally (see e.g. this pervious blogpost).

One of the key concepts in the enterprise architecture discipline is that of a principle. Different interpretations of this concept, naturally, exist in practice. For example:

A principle signifies a point, or points, that allows for the formation of a norm or rule that guides the development of ethics by which you operate (IBM, 2007)
A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance (TOFAF9)

Even more, in the book “enterprise architecture – creating value by informed governance” it is proposed to distinguish between:

Principles as inherent laws – referring to properties of a system that can be observed and validated
Principles as imposed laws – referring to properties of a system that can be validated
Guidelines – referring to properties of a system that are specific enough to provide guidance to operational behavior to make it fit within the borders set out by imposed laws.

Indeed, the field of enterprise architecture is mostly concerned with the latter two. Obtaining agreement on what exactly entails a principle, or attempting to explain the concept to newcomers to the field can be quite challenging. Recently I found a way to explain the concept by using an analogy from the field of (classical) music.

Consider the situation where a composer wishes to compose a symphony. Even though the “rules” for writing a symphony are rather loose, there are certain “principals” that have to be followed none the less (as a side note: it is interesting to note that the word symphony derives from Greek, meaning ‘agreement or concord of sound’). Beethoven’s 5th symphony clearly falls in the category of symphonies. As such, one can argue that Beethoven followed the principles rather neatly when composing this work. However, Shostakovich’ 13th symphony is a whole different story as it consists of a number of songs. Therefore, one can argue that Shostakovich bended (or even broke) the rules somewhat.

Back to Beethoven’s 5th symphony. It can be argued that the actual score of this piece – i.e., the result of the composing process – is its “design”, whereas an actual performance is its implementation. The design is strict: every note by every instrument is clearly mapped out. The composer also has the opportunity to add clues as to how the piece should be performed: tempo, speed, punctuation etc.

These clues can be seen as principles indeed for the conductor when a performance is rehearsed and executed. Again, the conductor has certain liberties with respect to the performance as be seen by comparing these two performances of Beethoven’s 5th:

In short: similar to the concept of (enterprise) architecture, the definition of what constitutes a principle is not very interesting in practice. Of more value is a discussion of what one wants to achieve using principles. Sticking to TOGAF’s “qualitative statement of intent” seems good enough indeed.

This leaves the question on how principles should be formulated in practice. This is a topic for yet another blog post (soon to follow). However, as can be seen in the simple example of classical music: more restrictive principles lead to more predictable results … provided one chooses to follow the principles!

Good intensions are not enough

2010-08-20T21:15:00.002+02:00

In many discussions as of late, I have noticed that people tend to think of (enterprise) architecture as a communications game. For example:

getting on the same page with respect to terms : what do we mean by application, process, product, service, etc.
getting to grips with how we talk about change : what do we mean by current state, baseline, target architecture, building block, etc.
getting to grips with terminology in different segments and domains in the enterprise

The list goes on and on. One of the top 3 things that people list as being a succesfactor for an architecture project is "help us talk to the other guys". Indeed, in many cases we see the intension is there: people want to talk to their peers in other departments, projects etc. If we all agree that this is a good idea, then how come it doesn't happen?

This brings me back to a previous claim: doing architecture - even with standards (like TOGAF) that people tend to think of as being IT-centric - is about the people. Helping them talk to and understand each other better will improve enterprise effectiveness.

Question to the reader: if you have any good approaches, examples, workshop forms, or other ideas to do these, let us know!

TOGAF: make it about the people

2010-08-17T04:18:00.002+02:00

As the enterprise architecture discipline matures, more and more enterprises adopt open standards such as ArchiMate and TOGAF to deliver value to their enterprises. Indeed, most organizations realize all too well that both standards make some serious assumptions on how we see our enterprise (as a system that (a) has state, and (b) can be decomposed). As long as we - the architecture professionals - keep our eyes on the ball and know what we're doing then we should be ok, though.

In the next few weeks I will post some observations and lessons learned in the form of short articles that may be useful for others. Here's the first one: key to successful architecture projects (with our without TOGAF) is to make it about the people. Just doing "stakeholder management" as TOGAF recommends isn't good enough. Take an interest in the people that make the organization. Know, that the TOGAF framework with all its steps, checklists, guidelines etc. is only there to help you do (part of) your job better! Enterprises are about more than IT or alignment!

Business Functions & Granularity

2010-06-25T15:31:00.013+02:00

In a previous post I already commented on the use of the business function concept in ArchiMate. A particularly tricky discussion that I frequently have during trainings and in sessions with clients involves the granularity of these services. It appears that there are two main options:

Business functions map to "activities" in the sense of "primary and secundary activities" in Value Chain Analysis. In this case, many processes belong to a specific business function.
Business functions are more finely grained and map on a competence that is recognized in an organization. As such, they are more closely linked to administrative organiztion type of research. In this case, several functions may be necessary in order to fulfill a particular process

Where the former view has the advantage of ensuring closer links between the field of enterprise architecture and strategic management, the latter appears to have the advantage of providing a mechanism for modeling the reusable building blocks of organizations. I came to appreciate this later view more after some good discussions with several clients and colleagues in the Netherlands as well as in Belgium. In this blogpost I will sketch some of my ideas and invite readers to comment and sheir their experiences in using the Business Function concept, especially when creating ArchiMate models.

The first principle that I'm proposing is to make a very tight link between business functions and business objects. That is: they have a granularity such that they mainly manipulate a single data object. Typical examples, then, are functions such as preparing an invoice, performing tax calculations, preparing a product for shipment, digitizing a document, et cetera. Note that these functions have a granularity such that they are reusable across business processes.

The logical next step is to link these functions to processes. Due to the relatively low granularity of business functions, business processes may be more coarse grained at the architecture level, which is a good thing. As is customary in ArchiMate, these businesses processes realize business services which represent the behavior of an enterprise to its environment; nothing new there.

In this scheme, business functions can be seen as "the things we need in order to be able to fulfill a business process". However, so far we've only proposed to tie them to business objects (by means of the access relationship in ArchiMate). We also need to tie other means to these functions. The main construct to be used here is that of an application service, which represents the functionality of applications that are available in the enterprise. The following example illustrates the concept so far:

By adding a layer of business functions between business processes and the means that are used to fulfill these processes, it may seem that models become needlessly complex. This is, however, not the case, as there is a big diffrence between the model (i.e., all the knowledge of all the concepts on the model) and its current representation. For many stakeholders one will generate views on the model which show only the relevant parts of it. For example, one my generate a view with processes and include the derived relationships between a process and the data objects that are manipulated in the process.

Derivation rules are relatively straight forward and the more sofisticated toolsets support these derived relations. For example:

process having acces to a business object is a process using a business function having access to that data object

The main advantage of such an approach, in my opinion, is that the business functions are easy to recognize and use in practice. They form a good starting point for modeling, and as well as provide a good starting point to gain insight in the architecture of enterprises.

On languages for enterprise architecture

2010-04-29T11:10:00.003+02:00

Over the last few months I've been working as a consultant with a group of architects in a large organization in the social services sector in the Netherlands. The group is 'heterogeneous' in the sense that people with different backgrounds / mindsets are involved, e.g.:

Architecture is intended as a means to set a vision "versus" architecture is intended as a process for governing change
Architects with a business orientation "versus" architects with a technological orientation

Despite their differences, it is interesting to see that this group at the same time shows a lot of cohesion. There is definately a shared sense of purpose: help to make the organization more effective. This shared purpose leads to a a log of conversation / shared initiatives etcetera. So what can possibly go wrong?

One of the things we learned is that due to different backgrounds, education, past experience etcetera, real communication is tricky. The well-known problems with overloaded / abstract / ill-defined / ... terms made it difficult to get things done. Indeed: without communication it is impossible to co-operate effectively. To improve communication (between architects as well as between architects and 'the rest of the organization'), a choice was made to introduce a common language for enterprise architecture: ArchiMate (with BiZZdesign Architect as a supporting tool).

The ArchiMate language offers concepts and relations to discuss many aspects of enterprise architecture. Some researchers / practitioners have argued that it falls short in expressing things like organizational culture, social interactions etcetera. Even more, ArchiMate has been critisized for having so many concepts and relations between these concepts that it is hard to use. However, at the same time ArchiMate has been praised for being so rich / expressive.

Back to the client. In the organization at hand, the group recognized the potential as well as the complexity of ArchiMate as a language. We have started (and by now: completed) a project where we went over the entire language, concept by concept, and selected those that are meaningful for this group/organization. Even more, for each 'aspect' of the organization we wanted to included, we discussed at great length how to model this using the custom ArchiMate dialect.

The end result is impressive to say the least, even taking into account that we have taken quite a bit of time for the project. On the one hand, there is a body of knowledge (well documented in a formal model and supporting documents) that answers the question how we wish to document architectures in the organization. More importantly: in creating this body of knowledge, the discussions have led to improved dialogue and shared understanding.

Lesson learned: it's about the people, get the language right and get the work done!