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.

SOA Magazine

SOA Magazine is a new

bi-monthly publication dedicated to providing specialized SOA articles, case studies, and papers by industry experts.

The SOA Magazine is brought to you by SOA Systems Inc. and Prentice Hall/PearsonPTR and is officially associated with the "Prentice HallService-Oriented Computing Series from Thomas Erl."

Issue I, September/October 2006.

Transitional Architecture

An interesting article from IEEE's IT Professional journal entitled ENTERPRISE ARCHITECTURE - Transitional Architectures for Enterprise Evolution by Murat Erder and Pierre Pureur.

The article describes transitional architectures, and introduces the idea of change in architecture avoiding the sometimes difficult direct from current to the "to be" architecture leap.  They propose what they call a prescriptive approach using a series of achievable application plateaus and architecture waves that help to ensure the achievement of business value with each transition  towards the to be architecture, and avoiding being in a constant state of transition. 

Basically, a series of architectural rest stops on the path to the final destination.

In this article, we offer our version of the prescriptive approach:  Why not briefly document the current state of the architecture, define the desired state at the conceptual level,and finally define transitional architectures on the way to reaching that goal? In other words, we introduce the idea of change within the architecture process.By following this approach,you will quickly learn which areas you need to focus on before moving forward with the architecture models and blueprints. Our method also yields several important benefits,including a focus on delivering architecture features that matter most to the business; effective risk mitigation, expectation management, and requirements traceability; and lower costs.

The article is very readable, and may be of interest to developers, designers and business analysts as well.