elemental links

Business-Driven Architecture Archives: Creating a Blended Architectural Portfolio

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>

SOA vital signs: Harvinder Kalsi on Cisco's Internal SOA Initiative

Yesterday, the SOA Consortium released a new podcast featuring Harvinder Kalsi, an IT architect in Cisco's internal IT organization, on Cisco's internal SOA story.  Harvinder spoke at the SOA-C's December meeting in Santa Clara. 

Right after his talk, I tweeted "Cisco has great internal IT SOA story, could have listened all day".  My enthusiasm was for both the business-driven story and the speaker.  From the range and depth of insights shared, it was abundantly clear that Harvinder actively participates in every facet of Cisco's SOA initiative.  And really, we all agree the best way to augment your SOA knowledge is from other practitioners. 

This said, I highly recommend listening to the podcast of Harvinder's talk.  Also, if you plan to attend the upcoming IASA conference in Atlanta, be sure to attend Harvinder's keynote session. 

Here's the podcast overview from my post on SOA Consortium Insights:

"Harvinder Kalsi, an IT architect in Cisco’s internal information technology organization, presented an insight packed case study at the SOA Consortium’s December meeting in Santa Clara on adopting a holistic SOA approach in support of Cisco’s business model expansion and IT enablement strategy.

Setting the presentation context, Kalsi shared that Cisco views SOA as the policies, principles and frameworks that enable business capabilities to be provided and consumed as sets of services.   Starting with the business capabilities, Kalsi described Cisco’s business drivers, an expansion into software product lines, the corresponding business architecture work, defining business capability maps, and how Cisco’s existing IT applications, which were web services based, prevented the efficient addition or change of business capabilities.   For illustration, Kalsi spoke to Cisco’s Commerce Transformation initiative and the use of services to support pricing and promotion capabilities.

In describing Cisco’s SOA approach, Kalsi shared artifacts, anecdotes and tips covering their four-step maturity process, major design concerns, and SOA platform.  The SOA platform is comprised of these major components, service development framework, SOA dashboard, SOA registry, SOA gateway, business rules management, SOA governance and SOA governance lifecycle.  Drilling into the SOA platform, Kalsi spoke of implementation challenges and the techniques used to address them, including open source, open standards and network-based services.

Throughout the presentation, Kalsi took questions from attendees on a range of topics including user and application security, governance automation, reconciling new subscriber demand with operational performance, service identification, investment and prioritization and cost and funding models.

In closing, Kalsi spoke of SOA success factors across people, process and technology dimensions, including the importance of business participation and business ownership of processes, policies and rules. 

To listen to an audio recording of Harvinder Kalsi’s presentation and view the slides go here."

[Disclosure: Cisco is not a client of Elemental Links; however, Cisco is a founding sponsor of the SOA Consortium, which is a client of my company, Elemental Links.]

Sticky Quotes?

Are there certain quotes, passages, pictures, ideas that have stuck with you over time?  Perhaps they've informed, influenced or validated your work?  Either immediately, or after lingering in your background processing?  I certainly do.

The immediate impact ones you might expect for someone with a development and architecture background:

"There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity." --Frederick P. Brooks, Jr., No Silver Bullet

"The people can shape buildings for themselves, and have done it for centuries, by using languages which I call pattern languages.  A pattern language gives each person who uses it the power to create an infinite variety of new and unique building, just as his ordinary language gives him the power to create an infinite variety of sentences." --Christopher Alexander, The Timeless Way of Building

"Any intelligent fool can make things bigger, more complex, and more violent.  It takes a touch of genius--and a lot of courage--to move in the opposite direction." --E.F. Schumacher

The I'm more right than left-brained one:

"Imagination is more important than knowledge". --Albert Einstein

And many background lingerers.  Lately, the two pushing to the forefront as I work on my 'active information tier' concept are:

"Now when we speak of an information-rich world, we may expect, analogically, that the wealth of information means a dearth of something else -- a scarcity of whatever it is that information consumes.  What information consumes is rather obvious: it consumes the attention of its recipients.  Hence a wealth of information creates a poverty of attention, and a need to allocate that attention efficiently among the overabundance of information sources that might consume it." --Herbert Simon, Designing Organizations for an Information-Rich World (pdf)

"If killer apps will indeed emerge in nonobvious ways, the process can only be enhanced if applications are deployed in a context that provides more information than is actually needed for the application.  This will create opportunities to discover more important uses for the app than were originally intended…

It may soon no longer be possible for even gifted visionaries to imagine the next killer app. Extrapolation of the present will follow lines less straight and more recombinant than can be deciphered. In that case, we will need processes and technologies that will allow us to intelligently stumble upon the future."  -- Robert D. Austin and Richard L. Nolan, MIT Sloan Review, Summer 2005

And yes, some of these ideas are in conflict.  That, depending on your point of view, is either the frustrating or the interesting part.

Anyway, how about you?  What are your sticky quotes?  Leave a comment, post with a trackback, and/or tweet yours.

Assorted Links - January 17, 2009

R, the Software, Finds Fans in Data Analysts - NYTimes.com

OSS SAS alternative: "R is..a popular programming language used by a growing number of data analysts inside corporations and academia. It is becoming their lingua franca partly because data mining has entered a golden age, whether being used to set ad prices, find new drugs more quickly or fine-tune financial models. Companies as diverse as Google, Pfizer, Merck, Bank of America, the InterContinental Hotels Group and Shell use it. But R has also quickly found a following because statisticians, engineers and scientists without computer programming skills find it easy to use. “R is really important to the point that it’s hard to overvalue it,” said Daryl Pregibon, a research scientist at Google, which uses the software widely. “It allows statisticians to do very intricate and complicated analyses without knowing the blood and guts of computing systems.” It is also free. R is an open-source program, and its popularity reflects a shift in the type of software used inside corporations."

The StreamBase Event Processing Blog: Case Study: BlueCrest Capital Management

Event Processing case study from Streambase: "In 2007, just as the credit crisis was breaking, BlueCrest set up a team..to develop a state-of-the-art market data management system. BlueCrest trades 24 hours a day, six days a week, across multiple markets using a wide range of data feeds. As markets move day to day and week to week, BlueCrest needed to rapidly reconfigure data feed connections and plug the data into real-time models while optimizing management of the necessary data feed licenses. BlueCrest devised a solution that combines the rapid time-to-market event processing capabilities of StreamBase with the instant storage and retrieval functionality of Vertica. It provides a total market data management solution that is able to meet the needs of low-latency trading and the demanding innovation of their quantitative analysts to achieve greater profitability."

Nine BI Megatrends for 2009 > > Intelligent Enterprise: Better Insight for Business Decisions

Event Processing as BI Megatrend...sounds so 80's, nonetheless..."Event processing opens new analytical possibilities. Before the financial services industry cratered, that was where most of the work in event or stream processing could be found. Now, while algorithmic trading and other processes still consume this technology, the spotlight shines brighter on emergent applications in healthcare, telecommunications, government intelligence, IT management, gaming and Web analytics. Network events, sensor data from radio frequency identification (RFID) tags and surveillance data are among the new sources. Capturing events, correlating them and presenting the results of analytics in dashboards can potentially give organizations more actionable insight than traditional BI tools provide. However, to gain full business value, event processing must be deployed in an integrated fashion with not only BI and data warehouse systems but also process management and service-oriented architecture."

Joseph E. Stiglitz on capitalist fools: vanityfair.com

Economist Joseph E. Stiglitz on 5 key contributing factors to the economic crisis. Easy read, important to understand how we got here. "There will come a moment when the most urgent threats posed by the credit crisis have eased and the larger task before us will be to chart a direction for the economic steps ahead. This will be a dangerous moment. Behind the debates over future policy is a debate over history—a debate over the causes of our current situation. The battle for the past will determine the battle for the present. So it’s crucial to get the history straight. What were the critical decisions that led to the crisis? Mistakes were made at every fork in the road—we had what engineers call a “system failure,” when not a single decision but a cascade of decisions produce a tragic result. Let’s look at five key moments."

The financial crisis: Who's really to blame? - Dec. 8, 2008

a keep up with cocktail party/coffee shop conversations version of "What happened in 2008? Chances are you can't succinctly express your views on that complex question. But the American public will settle on one of four catch phrases over the next several months. Whatever bit of conventional wisdom wins out will have an impact on the economy. The contenders are as follows..."

What does a "would & could attend" IT conference look like?

Somewhere, on an index card, I made a note asking "what does a must-attend event for enterprise architects look like?".   The idea being that once identified, I could engage with the community to make that happen.  Of course, I jotted this down in early 2008 when folks were actually attending conferences.  It would be fair to say that as a result of budget cuts conference attendance dropped off a cliff in late 2008, and 2009 isn't looking any better, with many organizations scaling down or canceling events.

However, the lack of travel & training budget doesn't equate to a lack of need.  And sure, when done right, online webinars and conferences provide a good way to receive information and to some extent, interact with speakers and other attendees, but they don't provide for opportunistic connections and exchanges -- hallway conversations and such.

A recent "random thought" from James McGovern reminded me of my index card and got me wondering not just about the future, but also the near term.  What does a "would & could attend" IT conference (event) look like? 

Of the elements I've included in the blue circle above, which are most important to you? 

And how do you define them?  For instance, does a "credible speaker" have to be high-profile?  Or, could it be a lesser known, but experienced practitioner? 

Would you be interested in a highly participatory, un-conference type format? 

Can a program be short and yet immersive? 

How about topics?  What's of interest?  Would you rather go broad or deep?

Then, on the red constraints circle, what are you willing to put up with for a low cost, high value event?  A 30-45 minute sponsor talk (pitch)?  Follow-on conversation with said sponsor?

Or, perhaps a no-frills approach?  Bring your own lunch?  Hosting a small gathering at your organization?  Other ideas?

Is there a need to create a "would & could attend" event for enterprise architects and/or other constituencies in 2009?  If so, what does it look like? 

Curious to hear your thoughts...