Enterprise Abstraction

My First Paper - Implementing SOA at CISTI

I'm pleased to announce the publication of my first paper.  Essentially it's a discussion of my experience with the EA and SOA implementation process at CISTI over these past few years.  From the introduction:

As they seek new roles in the digital realm, libraries are finding it increasingly difficult to manage the complexity of technology implementation while continuing to cost-effectively meet their mandates as information providers. Many organizations find themselves dealing with legacy, isolated, duplicated and ineffective information systems. The practices of enterprise architecture and service oriented architecture hold much promise as methodologies to reduce complexity, to encourage and enable collaborations, and finally to rein in the beast of technology. Even libraries under budgetary constraints can benefit from knowledge of enterprise architecture and service oriented architecture best practices.

Anthony, Stephen K. "Implementing Service Oriented Architecture at the Canada Institute for Scientific and Technical Information." The Serials Librarian, 55(01-02), pp. 235 - 253.
DOI: 10.1080/03615260801970907

I invite you to view the pre-print version (PDF)

There was a much more involved than I first imagined, and it took much more time than I expected.  However, it's done, and it's in print - and I'm doing the happy dance.  I hope it will be of interest to members of the library community who are starting service oriented related initiatives, are interested in CISTI's activities in this area, or who just want to know more about the area of SOA in libraries generally.

I want to convey my eternal thanks to Karen Morgenroth, Jim Cole the Editor-in-Chief, Daping Tan, Richard Akerman, Jane Carbone, and my wife Tammy for helping me with this project, and for putting up with me generally.

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.