Brent Carlson,
LogicLibrary
While I certainly don't disagree with this assertion, we in the industry can't lose sight of the fact that operational governance/management is really the tail end of a well thought out and executed SOA initiative. Unless an enterprise is simply going to deploy a handful of simple and obvious services and call it good, it must recognize that architecture and design-time governance is essential to prevent its SOA from turning into ABOS (A Bunch Of Services) – point-to-point services that cannot be used across business processes and simply create another layer of spaghetti code.
ZapThink's Schmeltzer also recently commented, "SOA is gaining momentum as a way to build applications out of reusable composable component services within an organization.......we have to know what we are doing so that we are not combining services that shouldn't be combined." This quote cuts to the core objective of SOA--to thoughtfully build out and manage reusable services and to make them available to application developers. This production/distribution/consumption model is core to SOA, and applies not only to deployed services but also services under development or architectural review.
Certainly, at some point those produced services will be deployed and exposed through some form of registry function (be it UDDI, an ESB's native registry/proxy service, repository APIs, or even LDAP). However, thinking that you have solved your service management and governance problem by deploying an operational registry is like looking at an iceberg--the registry is 10% of the solution, and the bulk of our needs are "under the water" and not visible to the deployed service environment.
I believe quite strongly that organizations building out an SOA must put in place a combined design-time software development asset (SDA) repository/registry to support the architecture and software development lifecycle (SDLC) governance environments within that SOA – serving as a repository on the service production side (with links to file-level repositories like SCMs, document management systems, defect tracking tools, requirements management tools, etc. for SDLC work products) and as a registry on the service consumption (i.e., application development) side, preferably with deep integration into the developer tool of choice these days, the IDE.
What are some of the issues that this design-time repository/registry should address in establishing broad-based SOA governance processes within the enterprise?
• Architectural decisions are delivered statically: The once-a-year IT pow-wow where the EA team rolls out its vision for the next set of strategic initiatives is a highly ineffective way to deliver core IT knowledge. Automatically delivering these architectural governance documents through an SDA repository both keeps this information in front of the developers and eliminates the knowledge choke point that occurs when architectural knowledge is distributed through one-on-one interactions between the architect and developer. In effect, design-time repositories serve as a "force multiplier" that enables enterprise architects to consistently capture and automatically deliver their knowledge to the larger IT community.
• Architectural governance is ad-hoc and doesn't scale: For enterprise architects to be most effective within an IT organization, they need to be actively involved in reviewing and providing advice to IT projects; both projects that are responsible for producing reusable services and those projects intending to consume those services. An enterprise architect is by nature a busy person involved in and responsible for a wide variety of activities. It is easy for an enterprise team to lose track of their governance responsibilities within the larger IT community. Since development project teams are usually under heavy pressure to deliver on time and under budget, they are not likely to actively seek out members of the EA team if that team is not responsive to their review checkpoints and deadlines. A design-time repository that automates and documents the IT project review process helps to ensure that enterprise architects actively and consistently guide IT projects down the right path both technically and business-wise.
Ultimately, the success or failure of an enterprise's SOA is based upon the ability of that architecture and its underlying implementations to meet business objectives--improved flexibility and reduced IT cost. Applying architectural and design-time governance consistently across SOA projects is core to meeting these objectives, keeping the business "dog" in charge of the IT runtime "tail."
biography
Brent Carlson is vice president of technology and co-founder of LogicLibrary. He is the co-author of two books: San Francisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey). He also holds 16 software patents, with eight more currently under evaluation.
