NETTING IT OUT

We believe the best use of the new architecture strategies--service-oriented architecture, event-driven architecture, process-based architecture, Grid-enhanced architecture, and real-time/right-time architecture--is a combined use. We need to blend these strategies in order to use the correct strategy in a given situation, and we need to use multiple strategies seamlessly within the course of a business transaction.

This mixing of architecture strategies will result in a new blended architecture. This architecture has an enterprise size and impact, and it needs to articulated and realized from an enterprise point of view.

However, an enterprise point of view does not mean traditional enterprise architecture. Our blended architecture will transcend the blueprint stage to a realized architecture with tangible products to be used by the project teams building out your business solution portfolio.

The new architecture strategies are powerful because they augment existing application, information, and infrastructure assets. They are really connection-oriented strategies, which bring our assets together in business-focused flows, breaking the traditional boundaries of applications.

Since the power is generated from our assets, we need to ensure we have a solid parts catalog to work from. So, along with changing our enterprise architecture practices, we need to rethink our IT architecture portfolio practices. We need to understand the value of our assets not just to the business problem at hand, but also to the portfolio as a whole. We need to actively plan and manage at the project, asset, and portfolio levels.

We refer to this three-pronged approach--blended architecture, architecture realization, and IT portfolio management--as Business-Driven ArchitectureSM. This report, the first in our new series, reviews each of the architecture strategies you should be considering for your blended architecture and sets the stage for blending.

ARCHITECTURE STRATEGY CORNUCOPIA

Exciting New Architecture Strategies

There are five compelling architecture strategies currently vying for corporate IT adoption. The front-runner is service-oriented architecture (SOA), but close on the heels of SOA are process-based architecture, event-driven architecture, Grid-enhanced architecture, and real-time/right-time architectures.

What we find interesting, and a bit perplexing, is that organizations believe they need to choose one of the strategies over the others. We refer to this phenomenon as “architecture zeal.”

Organizations are falling victim to architecture zeal--we just got SOA fever, or Grid fever, or business events fever. At the onset of zeal, everyone is happy, because there is a common architecture in place to advance the projects and the business solution portfolio. But then, sure enough, zeal fades. And the fade starts with the emergence of the 20 percent (or so)--those business problems not easily addressed with the chosen architecture strategy.

Sure, SOA is great in transaction-oriented scenarios, but it is not an efficient way (yet) to process an analytic request, which churns through volumes of data. Business events are a great way to inform and act on something notable, but when everything becomes an event, the overhead is untenable. Not only can the wrong architectural approach add extra expense and complexity to the problem at hand, it degrades the integrity of the architecture as a whole. Imagine if every sales transaction were a business event. How would we find the notable sales transactions--those that we want to act on differently? The sales for our best customers or sales with suspicious origins may completely escape our attention, because the business event pipeline is flooded with important, but not notable, things.

As zeal fades, we see one of two things happening: Organizations declare the architecture a failure, or they start to bring in exception side architectures. The side architectures spring up in isolation, a project at a time, without consideration for others that may follow. What starts as one-size-fits-all ends up as one-size-for-many, with custom tailoring for the rest.

We believe this is a problem that can be easily avoided. Organizations shouldn’t be looking at these strategies in isolation; the strategies need to be considered collectively. The strategies should be mixed, as part of an architectural portfolio. Then we can select the right architectural strategy in each situation. But we shouldn’t stop there. With merely a menu of strategies to use, we need to take the next step.

We need to blend the strategies to work together, so we can seamlessly use different architectural strategies within the course of a business interaction. Now when our most important customer places an order, using our service-oriented Web site, the notable event not only informs us, but also invokes a promotions service, which tailors a special offer for that customer. We can send the customer this offer via email, or it can be available to her as a business-process-in-waiting, activated when she makes her next contact with us--in person, on the Web, or on the phone.

This is the true promise of the architecture strategies, used together to create what we call a “fluid enterprise.” In a fluid enterprise, lag time is squeezed, traditional organizational boundaries are dissolved, supply chains are optimized, information delivery is sped up, and attention is focused at the edges--where the customers are.

While this blended approach can bring great power to our businesses, it won’t help us one iota if it is executed poorly. We can’t take on this enterprise architectural blending activity with a traditional enterprise architecture mindset. We need more than a blueprint to make this happen--we need a realized architecture that can be easily used by projects. We need our architecture to be actionable.

But it isn’t just our architecture practices that need adjustment. We also need to think differently about our portfolios: business solution, information, and infrastructure. These new architecture strategies augment what is in place. Their power is in connecting and altering the behavior of existing assets. For example, as inventory is received in a warehouse, a content management system can be automatically reposting the product page for the received product that had been out of stock. The assets in our portfolios are no longer sole-purposed applications or databases; they are also potential multiuse components and triggers to be exploited in the new architecture.

This is great, because we can leverage existing investments, but this can be problematic if our existing investments are poorly formed or underperforming. In that case, all is not lost, but some remediation will be in order. This remediation may include strengthening for performance, replacement of proprietary technology, dissection of monolithic code assets by business concept, or consolidating redundant code, databases, or infrastructure.

BUSINESS-DRIVEN ARCHITECTURE APPROACH

So to best serve our businesses, we really need to do three things. First, we need to combine these architecture strategies into a blended architecture, to bring new opportunity to our businesses. Second, we need to shake up the practice of architecture in the enterprise, so architects can execute our blended architecture, taking it from the whiteboard all the way into production. Third, we need to understand and manage the assets in all of our portfolios (business solution, information, and infrastructure) according to both their value to the business problem at hand, and to the portfolio in which they live. This will allow us to make better decisions as to the degree of architecture and development required as we introduce new assets and remediate existing ones.

To achieve this, we need a new approach to architecture in the enterprise. We believe architecture must have a strong bias to action, business opportunity, and project and portfolio advancement.

Our solution is an approach we refer to as Business-Driven Architecture (BDA)SM[1]. BDA is based on the simple premise that “architecture is a means, not an end.” Business-Driven Architecture dictates the following...