//September

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.

What do .Net Solution Architects need to know?

By |2008-09-08T16:02:20+00:00September 8th, 2008|Enterprise Architecture|

A friend and colleague, J.D. Meyer, asked me to consider this question, and I have to admit that it’s a bit of a tough question: What do .Net Solution Architects need to know?  (If you have an opinion, please go here).

Why so tough? 

For me, being a .Net architect means "applying various architecture skills to the Windows .Net platform."  We could just look at the intersection of architecture and platform and go from there.  This is a narrow scope: only platform-specific information.

On the other hand, there are a great deal of topics in architecture and engineering that are not specific to any platform.  We do a great service by providing a consistent message that allows architects of all stripes to seamlessly blend good practices with an understanding and knowledge of the platform.  This is a wide-scope: take best practices and apply them to a particular platform.

I tried to create a Venn diagram to illustrate these intersections (off the top of my head) for a small subset of practice areas.  This is what I came up with…

intersection of architecture and platform  

So let’s scope that question a little… With an architecture guide, what problem are we trying to solve?  Are we providing:

Advice for solution architects who happen to use .Net, or

.Net technology-specific advice for solution architects

I asked J.D Meyer that question.  His answer: Both!  The following is a (mostly) direct quote from his e-mail back to me:

I’m a principle-based, platform kind of a guy so I tend to focus on principles, patterns, and practices that are tech agnostic.  But we need to provide specific guidelines as well.

You can see that the big up front part of these guides are tech agnostic … and then tech guidelines are pinned against the backdrop:

· Improving Perf Scale (check out the first few chapters) – http://msdn.microsoft.com/en-us/library/ms998530.aspx

· Improving Web App Security (check out the first few chapters) – http://msdn.microsoft.com/en-us/library/ms994921.aspx

So, how I’m solving it now is … a thin, lead principle/pattern based guide as much as possible … and a KB, where the KB has how-to’s, cheat sheets .. etc. for applying it to the technology.

That’s the working model so far.

Here’s the last WCF project:

· The KB: http://www.codeplex.com/WCFSecurity

· The Guide: http://www.codeplex.com/WCFSecurityGuide

So, there you have it!  When providing advice, from Microsoft to all of the brilliant folks who live in the "real world" using our tools and technologies, we want to provide both the high-level principles and patterns, as well as the detailed level: here’s how to use all this good stuff in .Net.

My ask: if you have some ideas of "What .Net Architects need to know," Please go to J.D.’s blog and share your ideas with him.  The link is here.

Applying DDD to IT Management: First failure

By |2008-09-03T15:14:00+00:00September 3rd, 2008|Enterprise Architecture|

I always learn more from failure than from success.  In that spirit, I’ll share a (small) failure with you.

In my last post (Working in the dark), I mentioned that I would be discussing the metamodel [domain model] underlying all the things we do in operating Microsoft IT.  In effect, I’m following the precepts of Domain Driven Design, and applying those concepts to the act of software development in an IT setting, from planning through requirements, development through deployment, operations through retirement.  I don’t know if I will end up with a federated domain model or a single unified model.  That depends on a lot of things.  In the spirit of agile: I forge ahead.

One of the core principles of my effort, first and foremost, is “Leverage before build” which is a fancy way of saying “don’t invent what already exists.”  That implies that I will look to the [domain] models that exist.  One of them is the Common Information Model (CIM) from the Distributed Management Task Force.   

To leverage the work of the DMTF, I want to start with their highest level information model (conceptual level).  From the concepts, I can understand the classes.  I’ve used this process before, and it works.  To the best of my knowledge, this is the process used by DDD.

I opened the CIM from DMTF expecting to find an Information model.  After all, the name of their effort was “Common Information Model.”  And I found out that my nice little plan was not going to work… because the DMTF didn’t publish an information model.  They published a detailed class model.

(Caveat: I’m no expert on DMTF deliverables.  I spent three hours perusing their site, reading docs, and viewing models.  If there is a domain model there, I didn’t see it.  If someone does know of one, please send me a link.)

An example, from the DMTF CIM system model, looks like this (click to see the full picture):

CIM_System

Now for my controversial statement: This is not a good communication mechanism for information modeling, especially when sharing with people who are not already part of your project. 

I love Class models.  They are great!  Unfortunately, they are not a domain model that business people can use.  It is not a model that I, as a potential adopter of DMTF models, can use.  I need the business concepts first, to make sure I can align and/or adopt. 

There’s an information [domain] model under the DMTF class model.  That much is discernable.  But it is not explicit.  It is not exposed.  Both class models and information models should exist.  But if I have to choose one, I’ll start with the information model. 

(Caveat: I’m aware of their CIM metamodel.  It is a model used to describe the CIM meta-elements, not a conceptual model that serves as the foundation for the CIM object model).

So, while I’d like to consume the DMTF work, I’m afraid that the published models of the CIM are not appropriately modeled for me to consume and leverage them.  I could re-model them in my own UML environment… but what value would I gain?  I’m not sure. 

Alas.