Toluu

Inside Architecture

Notes on Architecture, OO Design, and anything else that interests me this week...

Feedback requested: Information driven process designDecember 17 2008

An esteemed associate of mine asked me recently if I believe that a conceptual information model, created and delivered independently from a process model, can be considered useful when attempting to improve a business.  In other words, if you have an conceptual information model, can you use it directly, or do you need to produce a process model as well?

The answer, as is typical of EA answers, is buried in the question.  If the goal is to improve a business measurable (like customer satisfaction, or average dollars per order, or customer acquisition cost), then the information model is not useful by itself.  A process model that illustrates how the information is generated and managed must also exist.

So we will often need to develop both a conceptual model of a business and a process model for the business… but which comes first?  Must they be done in parallel?  Or should an architect create one before the other?

Personally, I know of cases where a process model existed long before a conceptual model did, and vice versa, so clearly the efforts are not contingent upon the other.  In fact, in the situation I am in right now, the business has defined a rich process model that has grown out of date.  I have separately developed a conceptual information model that includes concepts considered important by the stakeholders.

Now comes an interesting question: how do we take an updated conceptual information model and use it to improve a

Understanding SOBADecember 5 2008

Just ran across, quite by accident, a blog post from last spring from Johan den Haan on the "Architectural requirements for Service Oriented Business Applications."  This is a clear, consistent, well described web post on SOA and service architecture.  I recommend it highly.

Adopting a new technology like OsloDecember 3 2008

Sometimes, when something new comes along, the best way to see it being useful is to see it being used.  Think about it.  If I went back to 1960 and visited a family somewhere in the midwest of the USA, and explained a "computer chip" to them, would they see value?  Maybe.  Probably not.  Life is just fine as it is, thank you. 

But if I showed them how I could use a computer chip to make a simple and useful device, that could do the trick.

Oslo is a new technology for modeling, and many Microsoft-platform developers are unfamiliar with model-driven development in general.  I don't think the best thing is to say "it's cool" but to say "here is how you use it to solve a problem."

Microsoft IT is looking to adopt Oslo in a big way, and along the way, we will be going through all of those same growing pains.  We use modeling tools in many areas, and some teams are quite sophisticated in their use of modeling, but Oslo is a major step forward for the Microsoft platform, and we are excited to be adding this new tool to the arsenal.

As we do, I hope to be able to come back to you, in this forum or in some other one, to talk about the useful problems we were able to solve using Oslo.  I believe that "showing" is better than "telling."

But for those of you who are still curious, please jump over to the Oslo Developer site and download the CTP or read up on some excellent ma

Creating a distinction between business services and SOA servicesNovember 30 2008

I'm always a bit dismayed when I hear the following terms mixed up, or combined: SOA service and business service.  In my mind, these things are different.  In one sense, they are related, but indirectly.

A business service is a function (or capability) of the business that is offered to one or more customers.  Those customers are often  internal, because this scenario is often applied to corporate supporting functions. For example, the accounting business unit may provide "accounts payable" services to every business division of an enterprise.  Those divisions are internal customers.  The business unit is accounting, and the business service is "accounts payable."

In some cases, the customers of the function may be both internal and external.  Many years ago, the Carlson company took their marketing division and not only made it into a shared function, that their various internal divisions could use,  but that division was able to offer their services to the general market as well.  They provide a list of shared business services used by both internal and external customers.

The people who use shared business functions are "businesspeople" of all stripes.  They have work to do, and a business service is simply a way to do it.   A shared business service includes responsibilities, and therefore people who are responsible.  It is a kind of "sub-business" that has customers, and processes, and capabiliti

Software Reflects The Process That Creates ItNovember 26 2008

Of all the ‘laws of software’ that I subscribe to, this one is one of the most fundamental, and unwavering.  I cannot find an exception to it, and years of experience reinforce it for me.  I can look at a chunk of source code, or an operations manual, or even a build script, and see the effects of the software development process used to create the artifact.

Process affects architecture.  If you use agile techniques, you will not only get your results in a different amount of time and features will appear in a different sequence than if you used iterative spiral techniques, but the software itself will have a different structure, different patterns, and different interfaces.

Just making an observation.  Probably not even a controversial one, but one that bears making. 

Software reflects the process that creates it. 

Corollary:

If you want to improve the quality of the software you produce (regardless of how you measure quality), you can change tools, and you can change information, and you can change training, to your heart’s content… but the big effects will come from changing the process.