/Tag: information architecture

Traceability, the Solution Model, and Metamodeling

By |2008-08-26T11:05:42+00:00August 26th, 2008|Enterprise Architecture|

It is nice to point out, on occasion, when two different leaders in the architecture community are saying things that, when added together, become greater than the sum of their parts. 

First off, my friend and colleague Gabriel Morgan recently described the business value of creating a single underlying model to connect all aspects of a particular software project (from requirements through code).  He calls the model a Solution Model, and rests that model firmly on a metamodel that allows these underlying elements to be related to one another in a useful way.

His blog post, which is long and richly detailed, is not about modeling.  It is about value.  I recommend it highly.

"this blog is about understanding the value of modeling to a project team and is focused on helping Solution Architects gain a practical understanding of the value of modeling to, in turn, help explain its value to the project team for adoption." (Gabriel Morgan, from his blog)

The other contributor is Jean-Jacques Dubray.  He recently posted a very interesting article on "Model Driven Engineering" where he discusses many things, including the value of a metamodel.

"My recommendation to developers and architect is: metamodel (as a verb), metamodel completely and thoroughly and even if you don’t create a [Platform Independent] model of your solution and a compiler (based on this metamodel), write code with the metamodel in mind (this will end up looking like a framework of course). For instance, define precisely what a business entity is, an association, a business process, a task… Remember, you are NOT creating an OO model, you are creating a metamodel. Every solution domain has a metamodel. There is nothing absolute about it, the metamodel of an information system is different from the metamodel of an industrial process control system, and what works for a travel company may not work for an insurance company." (Jean-Jacques Dubray, from his blog)

What makes these blogs interesting is not that they are about the same thing.  They are quite different from one another.  What makes them interesting, together, is the deep and fundamental support that each provides to the practice of "using the metamodel."  This is a term that is not discussed much, but it should be.

The metamodel is the conceptual information architecture that classifies the information that we can use to construct solutions, understand problem domains, and create practices that insure that we build the system that we should build.  As JJ points out, the terms matter.  As Gabriel demonstrates, those connections are valuable.

The metamodel is key.  With it, we can tie the requirements to the design in a way that supports agility.  We can say, definitively, what the impact of a change in requirements will have, allowing us to select the requirements that we want to change in order to have a desired effect.  This is powerful, and necessary.

And it all starts with the metamodel.

Technorati Tags: ,

Enterprise SOA needs a Federated Evolutionary Modeling Environment

By |2008-07-30T10:33:00+00:00July 30th, 2008|Enterprise Architecture|

I’ve been thinking a lot lately about the gap between “what we have” and “what we need” in the Enterprise SOA space.  I think I have a need that is not yet filled by software.  (that I’m aware of).

I put up a post back in June about the difficulty in creating a common information model in a large enterprise, especially one with a federated environment like ours.  (CISR coordination and diversification models).  The feedback I got back was telling.  The majority of respondants told me what I suspected: developing an enterprise-wide common information model was so difficult that many folks considered it unfeasable.  (Actual words included things like “utopian” and “big design up front.”  I’ll stick to “unfeasable”).

That said, I have also stated in public that I believe, firmly, that SOA at the enterprise level requires some levels of agreement on the way that information is understood and coordinated.  Each business unit can own information that is specific to that unit, but in the areas of coordination, where there is value, the business needs to be able to communicate.

So, we have something that is hard to do (build a CIM and keep it up to date).  That something is useful (to get the benefits of Enterprise SOA).  So, why not take the software approach?  After all, I do work at Microsoft.

What business scenario would this tool need to support?

Basically: each business unit would submit their information model to a common repository.  The submitters are architects, and they MUST align the models in some way, even if it is just to show that there are differences.  Services are posted to the same repository, and must be lined up under specific information models.  In order to consume a service, the business has to agree to the information model.  Multiple competing models are allowed to co-exist.  What do we get?  An economic model of self-governance that produces an optimum information model: one where agreement is reached only where agreement makes financial sense.

Specific capabilities:

  • A business unit architect can consume part of an information model without consuming the entire thing.
     
  • A business unit architect can assert part of an information model without proposing the entire thing.
     
  • A business unit architect can offer services tied to their information model.
     
  • A business unit architect can assert that a portion of an information model is “standard” for their use
     
  • A developer, writing software for that business unit, can easily find and adopt their information model.
     
  • A project team can provide a report to a governance committee proving that they are conformant to local standards
     
  • An enterprise architect can run reports to isolate “points of difference” between business unit information models.
     
  • A system designer, intent upon consuming services from another business unit, can begin a workflow to insure that the consuming business unit agrees to the information model of the presenting business unit. (an “information adoption workflow”).
     
  • The workflow needed for a consuming business unit to agree can be custom-tailored to the organization.
     
  • Organizations that present a service have an automatic measurement mechanism built in allowing them to “charge back” the businesses that consume the service.  Various financial models must be supported (one time fee, pay per use, annual licenses).  This provides economic incentive for sharing of code, as well as the incentive to create services that align to commonly needed information models.
     
  • Built in support for the versioning of information models over time (including both past and future versions) allows the business to change their minds, and even chart their course.

That’s what my gut tells me.  This has some pretty interesting effects:

  1. Information architects have a clearly defined and critical role at the earliest stages of a project: get consensus on information model changes needed to allow the consumption of existing, lower cost services.
     
  2. Economics will drive good behavior.  No need for an Enterprise Architect to “design” good behavior. 
     
  3. Less emotion.  There will not be consensus on everything, and this model doesn’t require it.  Consensus will be reached surprisingly easily on some key areas, and it will happen without any architect looking to make it happen.  This helps remove politics from the picture as well.
     
  4. It is easier to adopt existing code than build new code if services, offered by other groups, aligned with the information standards of the consuming business, are already clearly identifiied. 

We may be closer than we think.  With bits from various MS products, and with Oslo coming, this vision is getting closer to reality.  It’s an end-to-end idea. 

Something to consider.  Comments?

Building Conceptual Models, Building Relationships

By |2008-07-15T04:18:41+00:00July 15th, 2008|Enterprise Architecture|

Building teamwork, at the enterprise level, is a tricky thing.

As a project team comes together to solve a problem, hopefully you find yourself in the same position that I’ve found myself in many times: with smart experienced people, all motivated to succeed.  Microsoft IT is chock-full of folks like this… and it’s a big organization.  Couple of thousand folks.  So, it’s pretty normal that when I start working with a project, there’s always one or two smart motivated people on the team that I’ve not had the pleasure to work with before.

Thus begins the ‘relationship-building’ aspect of teamwork.  Meet a new person.  Figure out what motivates them.  Communicate.  Share.  Build trust.

Nice thing about a project team: your success is managed.  The majority of the team members are measured by the success of the project, and often they are full time on the project.  People can work together to accomplish things fairly quickly.  This is not usually the case at the enterprise level.

MCj03308460000[1]When working with a distributed organization, virtual teams become more important.  Here, you find smart people, motivated to succeed, but they are nearly never full time.  Getting consensus and buy-in on common goals becomes a high-order problem.  Without it, there is no traction.  And with people contributing a few hours a week, or month, to your deliverables, a lack of traction can be the difference between delivering in June and delivering in October.

And so the ‘relationship-building’ aspect of teamwork, at the enterprise level, is an entirely different game.  At this level, you need to harness the things that people are passionate about.   You need to find the influencers, and influence them.  You need to make sure that subject matter experts feel engaged, and empowered, and heard.

Building a conceptual model is a great way to get that to occur.  Getting agreement on the concepts, and business rules, for a business can bring people together.  It becomes a way to build common ground, establish relationships, and get different people, in different parts of the organization to see value in working together.  It is a work product that people can feel good about, and that will be useful.

When you build the conceptual model, you build relationships with the people whose ideas you are capturing.  Which is more important… the work product or the relationships? 

Both.

Open Question: Common vocabulary: Blessing or Curse?

By |2008-06-21T22:23:26+00:00June 21st, 2008|Enterprise Architecture|

Requirements are an interesting thing.  We cannot assume that we understand the business, and their needs, so we ‘elicit requirements.’  And we write them down.  But "the business" is a collection of different people, and in order to be clear, we need to make sure that everyone use the same words in the same way.

Within the scope of a single project, this is not terribly difficult, but it is very tough to keep a single vocabulary across an entire enterprise.  It can be a substantial effort to create an enterprise-wide conceptual information model, one that illustrates the relationships between key business concepts for an entire enterprise.  (If you don’t know what a conceptual information model looks like, here’s a pretty good example from the US Department of Veteran’s Affairs.)  You have to get a lot of people involved to create an enterprise-wide model.

The goal is to create a common understanding that bridges across many projects.  This allows planners to create information models, and future state models, and suggest project changes that will bring the enterprise information together… at least in theory.  The goal is simplicity and consistency.

But how in the world do we achieve that goal?  Software reflects the requirements, and business people create requirements, and business people, as a rule, are not well versed in the intricacies of the common information model.  They are on a different track completely. 

Business people won’t use the "standard" words, and they won’t use them in a standard way.  Even if you get a project to create their own information model, how do you insure that it lines up to the "blessed from above" common information model?

We need to have a way to recognize that "project-level consensus" is going to be different from "enterprise consensus." 

So we have competing goals:

  • creating a simple information model for the enterprise, and
  • creating a consistent understanding between the people involved in the project. 

If we don’t get the project to align with the common model BEFORE software is built, then we built the wrong software, and we have to spend more money later to fix the problem.  But if we force the business to use "special" language, words that they did not create, then you won’t get consensus and clarity.  You risk the project. 

How much is it worth to you to get alignment on information models?  What processes do you use?  I’d love to hear from folks.