Michael Stamback's Blog

Product: AquaLogic BPM Suite Archives

The Choice: Innovation or Extinction

What is innovation? How do you achieve it? Does it come in a box? Today's market is one of increasing competition, with the spoils going to those who stay ahead of the innovation curve.

What does it take to really be an innovative leader in your market space?  All one needs to do is take a look at history to see that organizations that bring business and IT together to address the core business model tend to thrive, while those that do not open the door to competitors and fade into extinction. 

What do FedEx, Amazon.com, Nucor, and Southwest Airlines have in common? Each of these companies is widely recognized within the industry as having taken steps to combine business with IT, and to leverage that combination to disrupt their respective market spaces with innovative ideas.

FedEx developed technology that not only gets your package to its destination faster, but also tells you exactly where that package is along the way, reducing the potential for loss. The company is so successful that “FedEx” is often used as a verb to describe package delivery in general, regardless of the carrier.

Amazon.com did something similar, developing a new storefront that not only robbed traditional brick-and-mortar book stores of market share, but sparked a revolution in how companies connect with consumers.

Southwest Airlines, one of the few airline companies to avoid bankruptcy, broke ahead in a crowded industry by combining business and IT to create an easy-to-use online reservation system and innovative active email campaigns to promote cheaper flights. 

Steel producer Nucor utilizes an innovative combination of business and IT to keep the company profitable and growing – in a declining industry with multiple casualties.   

Innovation, however, is more than riding a wave. Today, innovation requires the agility to constantly redefine and refine the business, finding new ways to do business that keep the competition in catch-up mode. To accomplish this, you need a technological foundation that supports sustained innovation. BEA AquaLogic platform can provide that foundation.

BEA recently completed the next evolutionary phase of the AquaLogic platform.  When originally launched in 2005, BEA AquaLogic was positioned as service infrastructure for SOA.  Over time, and through the acquisition of Plumtree, Fuego, and Flashline, the AquaLogic platform evolved to address SOA and beyond.

Today, BEA AquaLogic delivers the SOA, BPM, and Enterprise Social Computing capabilities that allow organizations to achieve and sustain true innovation through the creation of next-generation dynamic business applications.

Applications have continuously evolved since the mainframe days to provide more and more value to the business, at increasingly rapid pace. Gone are the days of monolithic applications that are simply packaged and deployed on top of an application server.  SOA brought about a revolution in applications, breaking them into discreet, consumable parts that could be assembled and reassembled to meet new business demands.  On a parallel course with SOA, BPM, social computing, and other trends provide the business with more direct influence over its business systems.  Dynamic business applications are the next generation of applications, the convergence of all these trends.

Dynamic business applications allow business and IT to align in a more efficient, collaborative manner to bring about true agility.  They consist of bite-sized pieces and parts that are assembled in a process that allows easy modification of application behavior through changes to individual parts of the assembly, without having to go through a rigorous IT change control process. 

The prospect of this kind of agility might be a little unnerving to IT, since lack of control over this type of capability can breed chaos, which hinders business agility.  Here too the BEA AquaLogic platform provides a solution. With built-in, comprehensive governance over the entire life cycle of dynamic business applications, BEA AquaLogic can provide IT with the confidence that innovation doesn’t come at the cost of control. By allowing the business to make changes based on business decisions, IT can free itself to focus on more strategic issues. 

Dynamic business applications represent the next wave in business agility.  That agility breeds business innovation, and that innovation allows a business to be a force of change in the marketplace, rather than merely reacting to competitors.  BEA AquaLogic provides the foundation that allows the enterprise to take advantage of dynamic business applications, and to complete and sustain the transformation from spectator to innovator to market disruptor.

SOA Governance: When, Where, and How

SOA Governance is a complicated topic.  There are so many things associated with SOA Governance it can make your head spin.  There are technology elements, like registries/repositories, policy management, policy enforcement agents, security providers, service virtualization, and what seems like an endless list of other technologies, but there are also non-technical elements, like organizational structure, incentive models, and governance processes.  So this begs the question - with so many elements to SOA Governance, when, where, and how do I start?

 I'm in product marketing, and as such, you should expect an answer about which technology you should use, and whichever product I cover, you should assume I'm going to tell you it's that product.  After all, that's common of product people right?  Well, I'm going to take my product hat off for a moment and take an objective approach. 

There are two things to note up front.  First is that SOA Governance requires a mix of people, process, and technology.  Focus on one and not the others and you will get a partial solution to governance.  The second is that there is no wrong answer to when, where, and how to apply governance.

Let's start with when.  The simple answer is that it is never too late or too early to start applying governance.  However, the opportunity cost related to starting governance later rather then earlier is much higher.  Theoretically, you should start applying governance once you have a single service.  Unfortunately, that's not the typical case.  Many wait until it becomes a problem and their SOA introduces more chaos instead of solving their business problem.  The cost for having to course correct and apply governance once it's a problem is much higher then if you start earlier in your SOA initiative.  Bottom line, you shouldn't wait until you are experiencing pain to start enforcing governance in your organization.  If you had pain in your leg, would you wait until you couldn't walk before you went to the doctor? 

Next is the where.  SOA Governance should pervade throughout the organization, across IT and business boundaries.  Many mistakenly associate SOA Governance with governing services.  This is only partially true.  You need to govern the services that are built, both functional and business services, but you should also be applying governance across your BPM processes, as BPM processes tend to be consumers of SOA artifacts in addition to possibly being exposed as services themselves.   Finally, governance at the individual asset level can be overwhelming when trying to manage an entire project, so governance should be applied at the project level as well. 

Finally, there's the how.  This discussion could take a while considering how many aspects there are to consider, so I'm going to keep it high level at some entry points.  There are many ways you can get your SOA governance initiative started.  It really boils down to where your pain is and what you're trying to accomplish.  Here are some examples:

• You have been constructing and deploying services but now don't have visibility into what services exist, where they are being used, or what other assets they are connected to.  In this case you might want to start with a SOA Management solution to discover the services in your service network and get a snapshot of your ecosystem. 
• You're ahead of the curve and want to apply governance early on.  To do so, you want control over ensuring the right services are being produced in the right manner.  Here you might start with a registry/repository with policy management capabilities to catalog processes and services as they are developed and ensure compliance with rules on how they are developed.  
• Maybe you're an organization that is security and regulatory control conscience.  In this case, you might start by looking at a security solution.  A policy-based security solution that allows you to manage and govern your security outside the application code gives you the most flexibility to easily adapt to new security demands.   
• Next there is the notion of service virtualization.  Many organizations start here by implementing a service bus without realizing they are applying governance, although it's loosely applied.  Service virtualization is a common and efficient way to enforce change management, version control, and runtime policy compliance by breaking brittle point-to-point connections to backend processes and services and hiding the complexity associated with communication with those processes and services. 

The above are just a sample of how you can get started, but they are pretty technology oriented.  Earlier I had mentioned governance was more then just technology.  Common throughout all of the options above is the need for organizational structure and processes.  This is actually where you should start.  Without the right org structure and processes defined, the technology aspects have limited value without knowing the structure to which they apply.  In other words, the technology elements should be used as a means to automate the processes defined, and the organizational structure should be used to assign accountability and responsibility within the processes and other elements, such as vision, architectural direction, etc.

The above is obviously not an exhaustive list of everything that has to do with SOA Governance, as SOA Governance is a large and complex topic.  The bottom line is that you need to identify where your biggest pain or need is and start there.  Your SOA Governance framework can then evolve as your SOA evolves. 

Which comes first...SOA or BPM?

This past week I had the chance to attend the Gartner Application Architecture, Development, and Integration show and attended a session by Paolo Malinverno on BPM and SOA.  His presentation focused on the various aspects of both BPM and SOA and how they share a common goal - to increase enterprise agility.  While they can both be successful independent of each other, its the combination that really drives business alignment and success.  As one of my colleagues likes to say, BPM and SOA are like chocolate and peanut butter.  By themselves they are good, but they're best when together. 

During the question and answer session at Paolo's presentation, I thought a very good question was asked: Which do I do first?  BPM?  or SOA?  Talk to a BPM guy and they'll tell you BPM needs to be first.  Talk to an SOA guy and they'll tell you the same thing?  So who's right?  The answer is that neither is wrong, but neither is right either. 

The path that an organization takes in terms of which comes first is determined by the goals of that organization.  If no SOA investment exists, but they are looking to optimize processes that are heavily human activity centric, BPM is probably the best place to start.  If they are looking to expose business services for reuse and re-composition to meet new business demands, then perhaps SOA is the best place to start.  The bottom line, however, is that to truly be successful and agile, an organization should invest in both.

Many organizations are embarking down SOA to create reusable services that can be re-combined and composed in new ways to meet changing business demands.  So what's the best way to do this?  That's right....BPM.  BPM provides business analysts with a means to provide an understanding of how a process is orchestrated.  That orchestration can, and in most cases does, involve the use of SOA services.  This allows the business to get faster and better value out of their SOA.

So what about BPM?  If you are doing BPM without the existence of SOA, you run a risk of decreasing your agility while increasing your cost of ownership.  Without SOA, your business processes will continue to create custom, brittle application integrations that are non-flexible and have to be maintained.  So while you're getting return from improved process control, your ability to modify those processes and the IT components within them becomes limited without the use of SOA.

So, which comes first?  BPM? or SOA?  I think where to start is a business decision, but at the end of the day, both are required.