/2008

Alignment – the missing Viewpoint

By |2008-10-06T21:56:00+00:00October 6th, 2008|Enterprise Architecture|

The (ISO Standard) RM-ODP model is a powerful and well reasoned mechanism for creating Architectural descriptions (“architectures”).  Leveraging the IEEE-1471 taxonomy, and building out a visual style and standardized approach, there is tremendous value in learning and using this the RM-ODP (Reference Model for Open Distributed Processing), and I’m getting to the point of recommending it.

That said, there is a gap in one of the most fundamental areas of the RM-ODP model.  RM-ODP specifies exactly five viewpoints.  This term is defined by the authors of RM-ODP as:

A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns.

In other words, if you want to communicate with Joe, and Joe cares about 19 things, you’d better cover those 19 things when discussing the system with Joe.  He has 19 concerns, and we can group those concerns together into 3 viewpoints (for example), and provide a “visual language” (my phrase) that can be used to communicate those concerns.

The next sentence, from the RM-ODP Overview (ISO/IEC 10746-1), is the problem:

Five viewpoints have been chosen to be both simple and complete, covering all the domains of architectural design.

Simple?  Not so fast.  The views produced by RM-ODP are far from simple… but…

Complete?  I disagree.  Big disagreement.

For those readers who are unfamiliar with the RM-ODP, this model describes five viewpoints:

  • the enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part;
  • the information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;
  • the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution;
  • the engineering viewpoint, which is concerned with the infrastructure required to support system distribution;
  • the technology viewpoint, which is concerned with the choice of technology to support system distribution

(There are many things wrong with this list.  I’m only describing one of them here.  Another will be described in a later post).

One viewpoint that the RM-ODP forgot is the one that matters the most to Enterprise Architecture: AlignmentI propose that the RM-ODP be extended to include the Alignment viewpoint.

The alignment viewpoint is concerned with the strategic and measurable purpose for the existence of a process or business system, and the justification for changing the features, structure, and operational profile of a process or business system, at a particular time, and in a particular organizational and technical environment.

The key concepts here:

Process or Business System — This viewpoint is NOT limited to describing a technology or line-of-business application.  The views may (and typically do) limit themselves to business and informational views that do not illustrate any specific “ODP” system at all.

Purpose — The notion that a system comes into existence for the sake of fulfilling a purpose.  That purpose is described in terms of business capabilities, business processes, business policies, business quality metrics, and business information.  These explicit concepts describe the environment in which a system adds value. 

Justification — The notion that any change to a system has to be justified.  Enterprise Architecture is the business function concerned with insuring that all justifications align to the business changes implied by business strategy.  Insuring that justification is based on strategy is an activity frequently referred to as ‘alignment.’ 

Note that, in a mature organization, alignment must be demanded to justify a change in any system, not just a software system.  Changing a system requires care to prevent negative consequences on routine business operations, whether it is a system of people behaving with common goals, or teams behaving in a process, or applications behaving in a sequenced activity.

Some examples of Architectural Views that fall into the Alignment viewpoint:

Business Capability View — An illustration of the business capabilities of a particular business unit (at any level of a business hierarchy where clear responsibilities and accountabilities exist).  Concerns for a business capability view may include the importance to strategy, staff readiness, process uniformity, cost of IT maintenance, flexibility of IT change, uniformity of information, maturity of process measurement, and scorecard value of process performance.

Business Process View — An illustration of the business processes and process activities necessary to support one or more business capabilities.  May be demonstrated at varying levels of granularity, with the highest level representing abstract business processes (like “Marketing”) down to task level processes (like “Deliver Marketing Brochure to Publishing Team”).  Concerns may include role and responsibility clarity, efficiency, effectiveness, uniformity, delegation of authority, and service level management.

Enterprise Project Portfolio View — An illustration of the business change programs in place throughout the business and how they align to meet the strategic and operational needs of the business.  Concerns for an Enterprise Project Portfolio View may include overlaps by feature area, relative budget estimates by category, interdependencies by time, and feature delivery by time.

Enterprise Application Portfolio View — An illustration of the operational systems and processes in place to run the business, and how well those systems are prepared to adapt to potential risks and strategically driven projects.  Concerns for an Enterprise Application Portfolio view may include applications that are impacted by multiple projects in close temporal proximity, applications that share similar functionality but different data stores, applications that share data stores but remain inconsistent in their implementation of rules, and applications that with high risk metrics (risk of failure * impact of failure).

Enterprise Information Federation View — An illustration of the core informational elements of the enterprise (like “customer,” “product,” “market offer,” “shipment,” and “service request”).  Concerns for this view include addressability (the ability to find a unique data entity, using a readily accessible identifier, anywhere in the enterprise), consistency (the ability to insure that information that is shared by many people has consistent use throughout those who use it), and federation (the ability to apply the control of key data elements to the level that is closest to the team that needs or uses it).

Enterprise Technology Portfolio View — An illustration of the supporting business capabilities required by the business, and the use of shared technology platforms to meet those capability requirements. 

While I have not met anyone who had told me that these views should be in the “enterprise viewpoint” as described by RM-ODP, I’m prepared to defend the notion that the enterprise viewpoint does not, in fact, cover this space.  (A different post, perhaps, if it is necessary).

Understanding Governance as Decision Rights

By |2008-10-04T04:13:39+00:00October 4th, 2008|Enterprise Architecture|

Todd Biske, whom I respect for his writings on SOA, seemed to miss the mark in his recent blog post about SOA Governance and Decision Rights.  In that post, he said:

if you focus on education, you can allow individual teams to make decisions, because you’ve given them the necessary information to make the right decisions. If they don’t have the information to make decisions that will lead toward the desired behavior, it turns into a guessing game. Not only can there be confusion in what the correct decisions are, there can also be confusion on what decisions should be escalated up the chain. If we instead focus on creating policies and making those policies known so that anyone in the organization can make the right decision, we’re in a much better state.

Was Todd wrong?  Nope.  He was right on. 

In describing governance, Todd just described a useful, and workable, set of decision rights.  I don’t think he realized it, because the blog was essentially trying to refute the concept of Governance as decision rights!

What were those decision rights he describes?

  • "You’ve given [individual teams] the necessary information to make the right decisions" — Implied in that statement is the notion that the individual teams, having made the right decisions, will not have those decisions taken away from them by someone else.  In order for a team to make a decision, they must clearly have the right to make it and, here is the kicker: Management Must Respect That Right.  Want that to happen?  Be explicit.  Tell everyone what decisions we will let the team make, and then hold them responsible for making them.
     
  • "There can also be confusion on what decisions should be escalated up the chain" — to avoid that confusion, we must be clear, as Todd correctly points out, about who has the right to make which decision.  Where does a decision stop?  That clarity avoids red tape.  That explicit clarity is called "decision rights."
     
  • "If we focus on creating policies" — And here is really the confusion.  What are those policies called?  They are called "decision rights." 
     

SOA Governance is a subset of IT Governance, on all three aspects of Governance: design time, deploy time, and run time.  SOA decision rights are a subset of IT decision rights, which are a subset of overall IT policies. 

What we have here, is a failure to communicate.

Extending Professional Software Architecture

By |2008-10-03T21:33:24+00:00October 3rd, 2008|Enterprise Architecture|

Imagine a time when building architecture meant "sketches" that would vary from one architect to another, one type of building to another.  It must have been quite difficult for the skilled tradesmen to build anything more than individual excellence… to deliver repeatable quality… because the "instructions" they were working from were so wildly different from one situation to the next. In some cases, the blueprints may have been vague, or even inaccurate.  In other cases, they must have been maddeningly specific.

Software Architecture is still at that stage.  We have the UML, thank goodness, but we don’t yet have a good, reliable, standard set of ‘documents’ that we can use to describe an architecture in a consistent way… or do we?

One effort focused on moving Software Architecture to the next level of maturity is the ISO (International Standards Organization), working to create and sustain the RM-ODP (the Reference Model for Open Distributed Processing).  (Actually, the standard comes from a joint effort of three different standards bodies: ISO, IEC and ITU-T).

In May of 2007, the good folks behind the RM-ODP released a set of profiles for UML called UML4ODP.  This is a major move, and one that all architects should take note of.

The RM-ODP is cool because it attempts to describe the "set of models" that can be used to specify a software system.  A good analogy: The RM-ODP tells you what diagrams a set of blueprints should contain.  If you are an architect, and you use the RM-ODP, you can provide a "standard" set of blueprints. 

This is cool, because developers can then receive a standard set of blueprints from the architect.  The goal: to help the Software Development profession rise to a level of ‘repeatable’ quality. 

Using standard architectural descriptions, we can better estimate the cost of software.  We can encourage specialization on specific components, much as home builders can subcontract electrical wiring to one speciality, and the heating system to another.  We can use agile techniques on some parts of the system, and "spiral-iterative" techniques on others (if that appeals to you). 

We can even begin developing system services that can simply be ‘plugged in’ to a standardized architectural description (much like a building architect can use a stencil to draw a picture of a bathtub, knowing that it will be the right symbol, and size, regardless of which manufacturer is ultimately chosen to supply the actual tub).  (We are not there yet).

The RM-ODP indicates that a system should be described from five viewpoints: "Enterprise," "Information," "Computational," "Engineering," and "Technology."  

Personally, I don’t think that these five viewpoints cover the gamut.  As I dig, I will surface more viewpoints: perhaps two more, from what I can tell now.  Regardless, this is the place to start, and I highly recommend that folks do a little digging on their own, especially if you are more than a few years out of college (like me).

When software architecture does make the move to "profession" from "craft," which side do you want to be standing on?

Input sought: Actor – Role – Process Activity… an interesting domain model question

By |2008-09-29T00:36:00+00:00September 29th, 2008|Enterprise Architecture|

I have an open question.  I’d love to get community feedback.

A process can be decomposed into activities.  Who performs the activities?  Are activities performed by roles with actors assigned to those roles, or are activities performed by actors in roles?  In other words, is it a binary or ternary relationship?

Pedantic question, perhaps, but this is the kind of thing that causes heartburn when creating a domain model for IT management.  Understanding these relationships is important if we are to build software that allows an IT person to correctly capture and describe business processes.

Here are these two options, in detail…

View 1:

image

Ternary relationship: an activity is performed by an actor in a role.  One consequence of this connection is that a person or system (actor) is directly traced to the processes that the actor performs.  The assumption being that any actor can play any role in any process, including many roles.  It also assumes that an activity cannot be described using only a role, but MUST be described by both a role and an actor.  Another major difficulty with this view is that it is very difficult to demonstrate that conflicts of interest have been addressed, as required by corporate best practices and, in many cases, legislation.  By containing an actor within a role, it is possible to demonstrate that an actor has remained compliant.

View 2:

image

Two binary relationships: An actor behaves in a role, and an activity is performed by a role.  One consequence of this connection is that a person cannot be directly traced to the process, since an actor is part of a role, and a role performs an activity in a process.  This is a simpler relationship, and it allows us to describe a process activity as “performed by a role” without any notion of the specific actor that will fill that role.  This appeals to the notion of encapsulation, and allows us to constrain an actor to a role.  On the other hand, this structure does not represent reality.  The notion of a person, performing a role, within an activity is better for tracing the actual events, because a person may act outside of their assigned role, and perform an activity in another way. 

Potential resolution:

image

Supposition: Both views are correct.  From a planning perspective, we can insure compliance with policy by requiring actors to perform within a role, and attaching the role to the process.  Then, when recording actual activity, we would record that an actor, behaving within a role, performed the activity, regardless of whether they are actually assigned to that role.  This allows good auditing, while insuring that compliance to policy and legislation is demonstrable.

Feedback?

The reason I pose this as an open question is to ask you, gentle reader, if you view this relationship in a different way.  What does your experience tell you?  What concerns would not be addressed by the potential resolution, or have not been considered in the two views?

Addendum

Jim Ludden points out, in the comments, that I had not defined the terms involved.  So here goes:

Role

  • Prescribed or expected behavior associated with a particular position or status in a group or organization. (BusinessDictionary.com)
  • The actions and activities assigned to or required or expected of a person or group (Wordnet, Princeton University)

Actor

An abstraction of a person or group of people, described through an understanding of their motivations and pre-existing conditions.

Process Activity

A single logical step in a business process. (Source: WfMC Glossary)

Looking up the definitions was valuable, because it makes it more clear that the definition of a role is not independent from the understanding of the activities themselves.  In effect, a role is an assignment of activities to an actor.  Pretty much makes “option 1” a non-sequitur.  The rest of the analysis is useful, however, in that we can describe what a person Can do, and then in a seperate way, what a person Did do.  Thanks to JimL.

It takes a village to raise an idiot (Wiki Non Wisdom)

By |2008-09-26T06:16:00+00:00September 26th, 2008|Enterprise Architecture|

I love wiki technology.  I’m an editor on Wikipedia and I enjoy contributing to community-based content.  The idea that individuals can contribute what they know to the rest of the world, and have it accepted at face value, is tremendous.  It is also a bit weird.

Recently, I returned to the Wikipedia article that I kept meaning to get back to: the article on Enterprise Architecture.  This is an article that had grown and morphed steadily over time, with each contributor adding bits of content in an ad-hoc manner.  While many people had something to say, an unfortunate few took the time to consider that the resulting article was less readable, more opinionated, and less useful than when they started.

I was guilty of that same crime.

I had made minor edits to the opening paragraphs a few months ago.  I didn’t take the time to really clarify things.  I just wanted to add… And there’s the rub with community based content.  No one is responsible for insuring quality.

Seeing that some changes had occurred since I last looked, I sat down to re-read it.  What an awful bit of text!  It was long, poorly written, with redundant material, and interspersed with conjecture and opinion. 

This time, I tried something different.  I took the time to discuss bits of text with other contributors, and considered multiple sources, before making a complete rewrite.  I made it much shorter and more readable, trimming out information that either could not be proven, or belonged in a different article on Wikipedia. 

It is not perfect.  It’s wikipedia.  If you don’t like it, change it.

Of course, now that I mention it here, a few dozen folks will go look, and my article will be changed within a few days to be unrecognizable again. 

Oh well.  At least it’s more readable now than when I started.

http://en.wikipedia.org/wiki/Enterprise_architecture

EA Poster – The Business Functions of Enterprise Architecture

By |2008-09-17T21:15:00+00:00September 17th, 2008|Enterprise Architecture|

Not long ago, I got an e-mail from someone I had not met, directed from this blog.  He had used the diagram I had presented in a prior post (One EA Team, Three EA Functions) to convince his CIO that their company needed Enterprise Architecture.  Direct Quote:

“Today I presented EA to our CIO and he bought the idea. Your BPMN diagram was key to the sale cause we are used to deal with activity diagrams as part of our RUP projects and he understood the process perfectly.”

First off, I really enjoy getting feedback like this.  It is good to know that my efforts to (describe / educate / challenge / annoy) the business of IT planning actually has some positive effects.

What this particular reader did not know is that I go beyond providing the process model by itself.  I created a poster, based around that same diagram, with surrounding context.  That poster is on the door to my office.  I have also circulated it with many folks here inside MSFT, all with positive remarks.

So, in the spirit of sharing, and in the hope that someone else may also find it useful, I’ll include a link to a PDF file with the full poster that I use.  (For best results, print on 11×17 (tabloid) sized paper on a color printer.)

Business Functions of EA.pdf

Clarifying the Concept of Metadata

By |2008-09-17T03:42:00+00:00September 17th, 2008|Enterprise Architecture|

Metadata is a difficult word to define, or so it would appear.  After all, why is it that the best that Wikipedia can do is:

Metadata (meta data, or sometimes metainformation) is “data about data”, of any sort in any media. An item of metadata may describe an individual datum, or content item, or a collection of data including multiple content items and hierarchical levels, for example a database schema.  (Source: Wikipedia)

Ewww. 

OK, to be fair, that’s not the best definition I could find, but I did want to point out one problem with the way that Metadata is perceived in the world of computing.  Metadata is usually defined in some lame way (data about data) and then described through examples, to help people to understand the meaning of the term.  Those examples are often incomplete or even misleading, like the example above or this example from further down in the same Wikipedia article:

In the context of an information system, where the data is the content of the computer files, metadata about an individual data item would typically include the name of the field and its length. Metadata about a collection of data items, a computer file, might typically include the name of the file, the type of file and the name of the data administrator.  (Source: Wikipedia)

What is so bad, you might say, about this example?

After all, it conveys the concept of “data about data” using terms that the reader may find familiar.  That is true, but there are much more powerful, complete, and correct examples available, ones that would provide a richer context to an understanding of metadata, and perhaps an understanding of how important metadata can be.  In addition, by supplying a small set of metadata elements, the example tells such a small part of the story, that it errs by omission.  It would be akin to describing a political leader as “human” and supplying their date of birth.  There is considerably more information that is both useful and simple to collect.

For example, let’s say that someone sends you an e-mail, and in that e-mail is a document.  The name of the document is “Functional Specification for Vista.” You could draw all kinds of conclusions from that bit of metadata (the title). 

Now, you open the document and you find that it is a short document (one page).  On that page is a list of the people, and their business functions, who proofread text submitted to a commercial printing company called Vista Printing.  Or even better, it turns out it is a Powerpoint deck, created by a salesman, that shows pictures of how Vista Printing functions!

After examining the metadata, what was missing from our understanding of this document?

We could (and I argue, should) know a great deal more about an artifact like this one, before we can say that we understand it.  We need to know, at least, who, what, when, where, why, and how. 

  • Who created the artifact?
  • Who is the intended recipient?
  • Who has accessed it?  (And when did they access it, and what process were they performing when they did?)
  • What business process called this artifact into existence?
  • What business outcome was it intended to support?
  • When was it created (date)?
  • When was it created (in what relation to the beginning of the process instance in which it was created)?
  • Where was it created (physical systems used to create it)?
  • Where is its address (URL?) for it’s ‘official’ storage location on a network?
  • Why was it created (name of the process activity that required this artifact as input)?
  • Why was it created (description of the personal objective of the creator in creating it)?
  • How was it created (using what tools and techniques)?
  • How was it created (using what thinking / creative / collaborative process)?
  • How was it created (using what audit / change control / approval process)?
  • How was it paid for (which goes to the motivation of the person who desired it’s creation)?

While it is true that the creation date and file name are, technically metadata, they are far from reasonable examples to help people understand the concept of metadata.

To this end, I’ll suggest an alternate definition: one that I believe is simple, easy to read, and provides a better understanding than ‘data about data.’  It goes like this:

Metadata is the surrounding contextual information required for a person or system to “understand” an element of information in the context for which it was intended. 

Metadata answers fundamental questions about a bit of information, such as who created it, who may access it, what does it refer to, why it was created, and how it should be used. 

A sufficient amount of metadata is captured when a consumer of a data element is able to correctly place the information in context, even if that consumer is using the information for a different purpose than it was originally intended.  The list of fields considered ‘sufficient’ for one purpose may not be sufficient for another.

Of course, you may not want, or need, all of those questions answered.  It can be difficult to capture everything, and some of those difficult items may not be beneficial for any of the consumers of that information. 

On the other hand, it would be very simple, in many cases, to capture quite a bit of metadata, nearly always more information than we normally capture.  Capturing this information, and using it appropriately, can help in the automation of business processes, the correct categorization of information for retrieval (and use), demonstration of compliance to a standard or business rule, and the maintenance of appropriate information security.

The data that we frequently collect, like the user who created it, or the date it was updated, is not interesting if there is not a business process that ties to that data, either as a producer or consumer.  How many database tables have columns for ‘last modified date?’  How many business processes use that information?

So, whether you are working on a repository of information, or just creating the schema for a database, consider carefully what metadata you want to capture and how you want to capture it.  Ask yourself who, what, when, where, why, and how, both for fields and tables.  Ask these questions for all artifacts, including the documents, source code, and test execution logs.  Then, consider carefully if that information would be useful to a business process somewhere else in your system. 

Capture useful metadata.  You’d be surprised how valuable it can be.

Civil Engineering Analogy to Enterprise Architecture: Flawed

By |2008-09-13T19:29:46+00:00September 13th, 2008|Enterprise Architecture|

It is typical to see comparisons of Civil Engineering to Enterprise Architecture.  A number of papers from Gartner have made the comparison, as have many articles and conference discussions.  I have made the comparison myself.

It is a somewhat apt analogy.  After all, both EA and Civil Engineering are responsible for setting standards (codes) that constrain the efforts of other architects.

But this is a limited and flawed analogy as well.  Here is why.

Civil engineers envision this:

future_city_downtown

(Futuristic cityscape from CG4TV)

Enterprise Architects envision these:

future-city

(Futuristic cityscape from 7 art screen savers)

Notice a difference?  In the first picture, the buildings are pretty, but they are silos.  They are developed independently and do not interact with one another.  The "shared infrastructure" between these buildings is buried underground… (sewers, electric, phone, etc).  That paradigm has not changed in 100 years!   The only interaction is at ground level, where the front doors are.  The only "suspended" part of the image is a transportation system, but there is no evidence, in the image, that the suspended transportation system interacts with the buildings.  It appears only to avoid running into them.

The second image shows not only transport systems between buildings, but suspended sections of buildings.  Livable, workable, usable space between the buildings.  The way in and out of each building occurs at multiple places, and those connections are more than just for transportation.  In fact, how would you define a building in this city?   This is more akin to the problems faced by Enterprise Architecture.

An even better image is one that I couldn’t find.  It would have been to show the city in LAYERS, with buildings that support a PLATFORM upon which other buildings are built, or upon which those same buildings are extended, with each layer serving unique functions.  Perhaps the lower layer would include freight transport, the middle layer would perhaps include commercial and office spaces, while the top layer (closest to the sun and fresh air) would include living spaces and solar/wind power generation.

The civil engineering standards needed to produce a layered city are radically different from those needed to build a traditional city.  You’d need to allow for, or even require, the creation of foundations to support structures that exceed the needs of the bottom layer.  (e.g. a 10 storey building with foundations sufficient for a 60 storey building).  There would have to be a mechanism to insure that costs are not shifted in an unfair manner, and that builders could replace a lower-layer building without affecting the structures above it.

The point is that civil engineering, in practice, has not made the leap to layered cities.  (apparently, futuristic art has not made that leap either!)  Enterprise Architecture has. 

This is no criticism of civil engineering!  To be fair, it is simpler to envision layers in the cyber world of an Enterprise Architect, where distance is an abstract notion, you don’t have to worry about the deterioration of different materials, and both water and gravity are absent. 

The analogy between EA standards to building codes is flawed because the systemic constraints that these two professions must create, and the envisioned results they are trying to produce, are radically different from one another.  Comparisons between the professions are interesting, and somewhat instructive, but insufficient to advance the art of either one.

How BPM does, and does not, support people

By |2008-09-12T15:21:00+00:00September 12th, 2008|Enterprise Architecture|

Kudos to Andrea Westernien on her blog about the disjoint between the work that people do and business process automation.

Andrea, who blogs under the title of ‘Policy Based Business blog,’ used eloquent words to capture what I was originally trying to say in my (considerably less eloquent) posts (here and here) on the successes, and failures, of automated business process management. 

My posts were attacked by one BPM analyst, Bruce Silver (here), with a few other bloggers offering their perspectives (example here). Hopefully, many people will take the time to understand this concept by reading Andrea’s well reasoned, and well written, post. 

Andrea also describes a solution that she feels may help.  I have yet to evaluate the solution she cites.