Blog: A Tale of Two Architectures

IT budgets generally follow a fairly strict and predetermined process throughout the fiscal year. Managers are well aware of the fierce competition between the contending interests of IT. Service-oriented architecture (SOA), with its promise of reuse and interoperability across the enterprise, is often an easy candidate for funding. That's true all the more now, as successful examples exist and executives become aware of SOA benefits. We're past the hype and into the real world.

This is generally a good thing, but architecture is important in all aspects of software and even the best SOA will likely fail without good underlying architectures in the implementation of the specific services. Oddly enough, the inverse is also true. The danger is that the effort and resources put into one architectural discipline will be for naught and may appear as failures if they are let down by the other.

I live in Chicago, a city known for its architecture. The city has fantastic architecture in its buildings and also in its infrastructure. Both are necessary for a successful city where people live and do business. The city is a success because the city planners designed and built great intra-building services (such as water, electricity, telecommunications and transportation) and because the building planners (architects) designed and built great individual buildings. Investing in either exclusively would result in a failure. Even the most fantastic building would be useless in a city without the underlying services that make success possible in the environment at large.

The same is true in the ecosystem that is the enterprise. Investing in architecture only at the level of the enterprise with SOA (the city) is only useful if the architecture of the individual components and services (buildings) are also appropriately designed and built. Inversely, investing exclusively in application architecture can result in missed opportunities in the context of SOA and very often in duplication of effort.

This occurred to me once when I was working with a large company. They had been doing truly impressive work on application architecture. Much effort was devoted to domain-driven design and Agile development. Within the application silos themselves, elegant and effective domain models had been designed to enable rapid and expressive programming to accomplish business goals. Unfortunately, the investment was underutilized once interaction was required outside of the application. Because of a combination of legacy technology and the unrelenting approach of deadlines, there was too much duplication. The carefully crafted domain models were at risk of being undermined since they weren't the sole conduit through which data originated and was persisted. The situation made it likely that the rug would be pulled out from beneath the applications.

Yet, this organization was ahead of the curve. As I said, they had very good application architecture practices in place. The only remaining work to do was extend these practices to the enterprise at the level of SOA.

I've been an application architect. I can definitely say that there can be an "us versus them" mentality in respect to SOA and application architecture groups. This can be due, in part, to the perceived proximity to both technology and business groups. It is a necessity that SOA is close to the business—more so than in traditional application architecture, where analysts and architects carefully tease out details from domain experts. SOA architects must be much closer and more subservient to the business at a higher and less personable level.

Page Break

The "business" (as opposed to a department or line of business) can be difficult to conceptualize. This is only complicated by tendency for many developers to see these vague nonfunctional requirements often critical to successful SOA as fluff.

Many developers are used to being so close to the problem (and to the solution) that they think about it in the context of code. When faced with an immediate requirement, like "Read in and import this file," many developers and project managers don't appreciate the larger issue. What is happening here is the crossing of an intersystem boundary. This is even more pronounced when the source of said file is an external B2B party. Ultimately, this falls under the issue of SOA governance, but that's an article for another day.

Sadly, many enterprises today find themselves playing catch-up in both areas of architecture, and they don't manage the necessary balance and tradeoffs particularly well. Here are some simple strategies for overcoming these challenges:

• Respect System Boundaries. Really. Even if the other system is an internal application or if it's developed by the same group of developers. The rate of change may be different between any two systems. You are crossing a system boundary if your application is written against a schema from this external source (even flat files have schemas); you have injected a dependency into your application from this external source. System boundaries are pretty serious, and good governance helps ensure they are respected.

• Establish a common vision. Architectural representatives from both sides (SOA and Application) should meet regularly. These meetings should cover upcoming functionality on each side. Neither should get too far ahead in developing short-term solutions for immediate needs. Frequent communication should also reduce the amount of duplication, as each team can coordinate its development efforts. The meetings should be between technical leads, ideally architects and business analysts from each team. An enterprise-wide road map can be helpful, but don't get too carried away.

• Reuse principles from each discipline. They really are complementary. Leverage design patterns at both the application and SOA level. These are the common language of each discipline and represent shorthand for concepts that make communication far easier among software professionals. Many SOA patterns are built on top of traditional architectural patterns; communication at this level can help both sides to understand the goals and expertise on each side of the fence.

  To return to the Chicago analogy, this is like applying the same guidelines for planning water systems both within and between city buildings. Although they are quite different in specific implementation, they share a lot of commonality.

With a little guidance and communication, every enterprise can—and needs to—find its appropriate balance between architecture on the SOA and application levels. Only once this balance is struck can real success be achieved in an SOA. This is the inverse side of the company I highlighted earlier in which the best planning of the business needs, data flows and service requirements can be completely undermined by poor architecture of the SOA implementation themselves. Perhaps some of the confusion of SOA is that it is really a dual layered entity: the abstract business level architecture and the concrete service level architecture.

Dan Rosanova is principal consultant at Nova Enterprise Systems, a consultancy that specializes in enterprise applications and Microsoft BizTalk Server solutions. He has ten years experience delivering enterprise solutions in financial, insurance, telecommunications, and medical industries on Windows, Solaris and Linux platforms.