I published my first business-driven architecture paper on October 14, 2004, as a contributor to the Patricia Seybold Group. Today, I'm excerpting the introductory sections of that report. Why? For one, the content is still relevant. Two, the concepts presented here -- combining architecture strategies, architecture realization, portfolio management, fluid enterprise -- are foundational to my on-going work.
Since 2004, "process based architecture" has evolved into business process management (BPM). Some of the grid constructs (grid enhanced below) that I was intrigued by, and speak to later in the report, have evolved into virtualization and cloud computing.
Excerpt: Creating a Blended Architectural Portfolio, Brenda M. Michelson, Oct 14, 2004
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 I find interesting, and a bit perplexing, is that organizations believe they need to choose one of the strategies over the others. I 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, I 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.
I 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. I believe architecture must have a strong bias to action, business opportunity, and project and portfolio advancement.
The solution is an approach I refer to as Business-Driven Architecture (BDA). BDA is based on the simple premise that “architecture is a means, not an end.” Business-Driven Architecture dictates the following:
• The goals of the business must drive the composition of the architecture.
• The architecture must be defined, realized, and consumed with a bias for action and a healthy dose of pragmatism.
• The architecture must provide tangible products and services to the builders of the business solution portfolio.
• The IT portfolios—and the individual code, information, and infrastructure assets within them—must be understood and managed according to their value.
• The links between projects, architecture, and portfolios are managed collectively using business discipline.
</Excerpt>
