Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

September, 2008

Posts
  • Inside Architecture

    Input sought: Actor - Role - Process Activity... an interesting domain model question

    • 13 Comments

    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.

  • Inside Architecture

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

    • 0 Comments

    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

  • Inside Architecture

    On IEEE-1471

    • 1 Comments

    [I tore down this article.]

  • Inside Architecture

    EA Poster - The Business Functions of Enterprise Architecture

    • 4 Comments

    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 11x17 (tabloid) sized paper on a color printer.)

  • Inside Architecture

    Clarifying the Concept of Metadata

    • 8 Comments

    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.

  • Inside Architecture

    Civil Engineering Analogy to Enterprise Architecture: Flawed

    • 2 Comments

    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.

Page 1 of 2 (9 items) 12