Enterprise Abstraction

Library Architecture Principles

Michael Ridley points out an excellent article in Library Journal by Roy Tennant where Roy mentions a few thoughts that I think could be adopted as architecture principles.  In particular, I like:

• Build not for longevity but obsolescence
• If it doesn't have an API, it's not worth having

And one more that he does not explicitly mention, but that I think is a very important one for organizations newly undertaking architecture and technology practices:  become comfortable with the not knowing.

All too often I've seen all sorts of projects and initiatives fail due to the very human desire (some would say need) to know it all up-front.  This is impossible.  Deal with it. 

Yes, the architect will work with you to provide a broad scheme... blueprints if you will for the planned vision.  This is not a detailed plan, just an overview.  There are still risks, and unknowns.  As you work though the plan (via projects), you identify and manage the risk.  You cannot -- must not -- stall progress until all the unknowns are known.  You'll wait forever.

Service litmus tests

A few months back, a small group at my organization hired a consulting team to give us a running start on our SOA efforts.  In addition to some other consultation, workshops, and self-learning, we decided that we really needed to get someone in to give us the rough guide to getting things going.  During that process, we came to realize for the first time that we had really already been following instinctively most of the good SOA practices and principles, it's just that we'd never laid them out plainly, nor did we have a structured method to determine what should and should not be a service from our existing enterprise architecture components.

Our intrepid consultants identified a litmus test, with a series of questions that would help determine the answer to that questions... but was unable for intellectual property reasons to actually provide us with that list.

The article principles of service orientation (part 6 of 6) comes the closest I've seen to providing that list.  Essentially, ask the questions, is (or can) the component in question be:

• stateless
• discoverable
• autonomous
• loosely coupled
• composable
• abstract

If the answer to any of these is no, then you probably are not looking as something thats an appropriate service.  I usually pull out reusability as it's own separate test (if a service will not, or cannot be reused, then it shouldn't be a service).

SOA explained and defining architecture terms

By far the best introduction for the layperson I've seen on services and SOA is the article What Is Service Oriented Architecture by Hao He at xml.com.  It's slightly dated and get's mildly technical at the end, but it gets the idea across in a single page.   I particularly like the quote (and indeed personal architecture principle):   "Things should be made as simple as possible, but no simpler", by Albert Einstein.  Another excellent resource is the ABC's of SOA by CIO Magazine which is a bit longer, but broader in scope and more up to date.

I don't believe that everyone needs to know how the architecture process works within an organization.  Indeed, if you're running your architecture as a service, then most don't need to know much at all except what goes in (business desires) and what comes out (wonderful excellent plans and implementations that move the business efficiently forward).

I do believe that the business needs to understand the ideas of architecture, including services and SOA.  One of the most effective ways to do that is to define your terms in the context of your enterprise.  Services, web services, business services, product, offer, even client can cause all kinds of consternation and risk.  Particularly if the groups your communicating with not only don't understand the terms, but where each group and individual applies their own meaning to the terms.  Business terms must be understood uniformly across the business.

My humble advice would be:  as early as possible, take the time to sit down with your architecture business stakeholders and define these terms.  Come to a consensus... even make up common terms if you must, but you must all be on the same page with the same nomenclature in the end.  Then, use the terms, and correct mis-usage.  The few minutes spent in the exercise will be worth a complete library of books and papers explaining these terms and concepts, and will be invaluable when you meet next time to discuss ideas.