Building an Incremental Enterprise That Works

It is possible to succeed in the short and long term as you grow you enterprise infrastructure if you stay focused on your business pain points. Here are some pointers.

It is possible to succeed in the short and long term as you grow you enterprise infrastructure if you stay focused on your business pain points. Here are some pointers.

Even as the roaring '90s fade into archival memory, we're still living the legacy of that era's rip-and-replace mentality and the flood of standards-challenged B2B solutions it produced. "Top-down" enterprise implementations foisted on companies by swarms of expensive consultants bearing even more expensive wares left IT organizations with a good deal of spaghetti code and even more skepticism.

As much as people want to be good citizens of rip-and-replace and top-down implementation, the fact is that most just don't have the money to do it anymore. Fewer still have the stomach for it, even if they have the cash. The good news is that you can stop feeling guilty that you have a limited budget and not enough antacids. Today it's rarely an ROI-friendly proposition to try to do everything in one fell swoop anyway.

Enterprise infrastructure doesn't have to be top down to be right, and you can grow your enterprise architecture incrementally if you start with a service-oriented foundation, plan carefully and tackle the electronic commerce monolith in a series of discreet steps. You can succeed in both the short and long terms if you stay focused on your business pain points, solving them one by one as you move gradually, but steadily, along the continuum toward integration nirvana.

The Four Ts: Practical Steps with BPM in Mind

One way to think of the incremental enterprise is by the "Four Ts." The first is Trouble, which we just covered: tight budgets, tight schedules, high return on investment (ROI) expectations and a whole lot of dissatisfaction. The second "T" is Technology, the third is Technique and the final is Triumph.

Technology requires the most attention because it is so powerful  a magic wand or a devastating weapon, depending upon the experience in the hand that wields it.

The first technology step is to carefully choose and deploy a service-oriented architecture (SOA). The SOA provides the foundation of a common infrastructure, enables flexibility, and provides a good way to implement and handle the growing phalanx of Web services. Suppliers in the SOA realm are, for the most part, mature enough to provide expert guidance and the proper tool sets so that you don't have to reinvent all those enterprise-quality wheels, such as dynamic load balancing, guaranteed delivery and high performance.

The services in your SOA should correlate and conform to activities meaningful to business, so when you choose and deploy them, be sure to understand and adopt business process management (BPM) as your way of designing IT projects. Doing so makes the projects much more business focused and more likely to succeed, which in turn sparks company support and management sponsorship of future steps.

If just hearing "BPM" makes you feel impatient or anxious, that's understandable. For more than two years the industry has been talking about the importance of executable languages for business process modeling and industry adoption and standardization. Even though the game is not over yet, notable progress has just been made with movement toward answering the call to "please give us one language so that we can go off and use it&" That's what OASIS is promising, and under growing pressure from major players such as Microsoft and IBM, all the various BPM groups and subgroups that attach themselves to the BPEL or BPML camps seem, at last, to be converging.

Converging or not, the great notion about business process languages is that they can minimize the requirements gap — that chasm between the business community and the developers who serve them. The BPM languages are now describing business processes so the business community can sink their teeth into them, and yet they're fully executable so IT doesn't have to wring its hands about how things are implemented.

The upshot is that you can take heart — there is no need to wait. Some integration vendors already have tools based on executable process languages. Make sure your vendor is buffering you from future standards changes by promising to migrate your articulated business processes to tomorrow's standard formats. If they are, your processes are safe, and you can start reaping the benefits of BPM today.

With a well-crafted SOA you're creating a blessed sense of homogeneity — the opposite of spaghetti. The services you need can be plugged into your SOA, Web services being among them. Not everything will be a Web service, of course, so you should also think about even expressing your legacy work into an SOA. While Web services play a vital and growing role, they won't necessarily take over your entire infrastructure.

Because you can plug almost anything into your SOA, the risk of losing business relevance remains a very real prospect as you push more pieces into the structure. How do you maintain relevancy? BPM enters the picture again. If you express each activity in a business process as a service that can be plugged into your SOA, you create a dynamic and agile infrastructure. Some of the activities in your business process are going to be Web services, with BPM adding needed business relevance.

'T-ing Off' Into Iterative Development

As you cross the border into the next "T" — Technique — you plug services into your SOA and use an iterative approach to building your enterprise. You should stagger incremental projects from the "must succeed" lead-off project, which is why the choice of pilot projects is so crucial. The pilot can't be so small that it's a toy problem that's interesting, perhaps, but not noticeably helpful to your business. On the other hand, it can't be so large and unwieldy that you risk loss of sponsorship, participation and meaningful results. Ultimately, the project must alleviate a legitimate and widely felt pain point. An example of something worthwhile to tackle is anything that is a constant source of frustration to your customers, particularly excessive queuing or lag time.

The key to successful iterative development is to never lose sight of continued interoperability while moving toward a new solution. You must demand solutions from your vendors that can coexist and add value to your current solutions  applications that permit you to remain productive while you extend the new architecture incrementally and untangle the skeins of old spaghetti code. Iterative development with the right solutions can assist you in successfully migrating from old ways of doing business to new. Keep in mind that you should migrate only when it makes sense for your business; the latest tech fashion isn't always the right thing to wear. Remember that EDI-based trade still supports one third of the U.S. gross domestic product

If you follow the iterative path well and faithfully, ultimately there is Triumph.

Once your pilot succeeds, you would do well to shout it from the rooftops and then promptly turn on your heel to get the same sponsors to begin fueling your next project&and then the next. Because service-oriented, process-focused, incremental integration satisfies long-term needs and justifies its cost with early and sustainable success, getting company movers and shakers on board becomes a much less daunting prospect.

If you happen to be in the midst of an SOA "make or buy" decision, keep in mind that "make" for a service-oriented architecture is very expensive. The general recommendation is to buy. As an invention of many wheels, the infrastructure requires innumerable enterprise-quality features to exist at the root level.

If you're going to buy, be demanding of your vendors and make sure they have a solid foundation for your SOA and that they possess true executable BPM language support that can be used to link services together. Your enterprise technology partner should not only be good at plugging new things in, but they should also recognize your legacy world and be equally good at embracing and leveraging what still works for you.

About the Author: A member of the BPMI board of directors and long-time advocate of BPM open standards, Jeanne Baker, vice president of Solutions Engineering at Sterling Commerce, is a frequent guest speaker and lecturer at seminars and conferences worldwide.