Enterprise Initiatives

If you have been following my blog recently you would have seen my previous posts that discuss the benefits of the various layers of the stack (mashups, data services, business processes). Although many IT folks talk about the benefits of SOA in terms of code reuse, the real benefit is in the ability for IT to adapt their systems at the speed that the business is changing. One of the best ways to accomplish this feat is to put tools in the hands of the business to empower them to dynamically alter the business rules as they change in real time.

In the old days we built systems with rigid rules and users were forced to adopt to the "laws of the system". Today, users are king and they expect systems to adapt to the way they need to use them. In order to satisfy today's tech savvy users we must build dynamic and customizable systems. We also need to make sure that IT does not become a bottle neck and hinder the rate of change that occurs within the business. The answer is simple, abstract the business rules into its own layer within the architecture and empower your users with the appropriate permissions to make the necessary changes in a timely manner.

Let's discuss the following order process example that I used in the post about business processes.



Now what if we had different rules on what a good credit score is? What if those rules were dynamic? Do we want to hard code these rules in the system and accept change requests from the business to every time they change or would we rather abstract them and give the business a tool to change them as needed? I'll vote for the later! Here is the same business process integrated with a business rule engine (BRE).



Here is a simple example of how the business can set up rules to apply different criteria to different customers.



In this example you can see that Gold customers get special treatment and will be allowed to proceed regardless of their credit score. Other tiers have higher standards applied to them. Now let's say that due to the credit crisis the company decides to apply stricter criteria on their customers and raise the minimum at each level by 20 points. The business can simply make these changes from the business rules engine interface which is most likely done from a browser. If the company wanted to add a Platinum user type, they simply add a record to the customer type table and the appropriate rule for Platinum customers in the BRE. Done! No change request, no priority setting, no change control board, no development, no testing, no rollout!

I also used a callout to point to a business rule lookup at the fulfillment process. Let's say that our company is an eCommerce seller for many different wholesalers. We may sell books, music, appliances, clothes, etc. but we are simply the middle man and don't own the inventory. Instead we sell, take a cut, and trigger transactions to the appropriate wholesaler for distribution. Each wholesaler has a unique set of business rules for their fulfillment process. In addition, we may add and remove wholesalers several times during the year. We have a standard business process for dealing with fulfillment but different wholesalers may have different rules due to industry specific or geographic requirements (age limitations, state laws, tax rules, etc.). Once again, an appropriate business person with the proper permissions should be able to make these changes as necessary without having to deal with IT.

Business rules have their place and purpose but they also come with some baggage. Like any other layer within the architecture, business rules need to be administered, maintained, and governed. Business rules need some level of change control, backup/recovery, and auditing like any other artifact. Most BREs either provide that functionality as well or hook up with other tools that manage artifacts (CMDBs, governance tools, etc.). But business rules are only worth the hassle if the business environment is dynamic. If the rules are static in nature, it is probably not worth the effort from an architectural stand point to create an abstract business rules layer complete with the appropriate security, auditing capabilities, etc.

The higher up the stack we go the more opportunities we create for the business to become agile. Business Rules create the ultimate flexibility and agility that most of today's businesses require. Implementing a BRE in your SOA is another great step towards IT becoming an enabler instead of a cost center!

As I have mentioned in many posts before, SOA built right can provide business agility and flexibility. Yesterday I discussed how to leverage data services and a few days back I discussed enterprise mashups. Today the focus is on business processes.



Separating business processes from code is an ideal way to build an architecture that enables systems to adapt more readily to change. Let's make believe that we are working for a large eCommerce site that sells many different categories of products from multiple suppliers and warehouses each with their own distinct business processes. Abstracting the business processes gives us some very important advantages:

• Creates a set of standard business processes for a consistent user experience
• Allows us to quickly bring on additional suppliers
• Allows us to change a core business process once and apply it to all suppliers
• Allows the business to make modifications to its processes with minimal or even no coding

Here is an example of an order fulfillment process.



This work flow speaks to my first point "Creates a set of standard business processes for a consistent user experience". The complexities of working with multiple suppliers, each with their own processes and systems is hidden from the end user. Regardless of what products the customer is buying and which supplier is fulfilling the order, the user experience is exactly the same. On the other side of the equation, bringing on a new supplier can be as simple as collaborating on a set of services to integrate the supplier's back end system to the core business processes of the eCommerce site. Had we not separated the business processes from the code, we would have to make modifications to our existing code base which is already running in production and would have to go through a complete testing cycle. Instead, we simply tell the business processes which set of new services to integrate with for the new supplier. All of the existing code is not impacted and does not need to be retested. Instead, we can just validate the new services and the new supplier flow.

Here is another benefit. Let's say that we just signed agreements with three new suppliers and have contracted to launch them all in 4 weeks. Without the separation of business processes from code, all three supplier integration efforts would have to be coordinated and most likely bundled into one build. This creates huge project risks because slippage in any one integration effort can delay all three. By separating the business processes from the code, each supplier integration can be implemented whenever it is ready. We can stub out a call for each supplier and assign the appropriate WSDL when the services are completed. For example, the "Fulfill Order" process could be an integration with SAP for supplier 1, PeopleSoft for supplier 2, a custom built fulfillment process written in Java for supplier 3, and a custom built fulfillment system written in .Net for supplier 4. The business and the business processes have no need to be concerned with the technologies behind the fulfillment process. They are only concerned with the inputs, the outputs, and the quality of service (QoS).

As we move up the stack it gets even better! Next post I will discuss the importance of business rules. Stay tuned.

A colleague of mine sent me an interesting article today called Don't give customers what they think they want. This article has a great quote from the early 1900's by Henry Ford, the inventor of the Model T. While talking about user requirements, Henry stated:

"If we ask customers what they want they’ll ask for faster horses".

If Henry would have implemented exactly what the users asked for (if he even could accomplish that) he never would have created the Model T. Instead of asking users what they want, we should ask them what problem they are trying to solve. The article recommends asking this same question in a more eloquent way by asking, "What is the desired outcome?" After all, it is the job of IT people to design systems, not the business. The business should know what they want to accomplish and IT should devise a few potential solutions and offer those to the business.

I have ranted in the past in a post called Why are you still generating reports?, how IT has a tendency to let the business design systems. If the IT industry would get the business to focus more on defining business problems and desired outcomes instead of telling us what to build, perhaps there would not be such a huge need for business process reengineering these days. In my 20+ years of IT experience, I have seen huge amounts of waste due to IT building low value solutions. This often occurs because a user with limited visibility into the entire workflow asks for a point solution for their small part of the world. Over time, IT builds hundreds of these point solutions which wind up creating redundant data entry steps and the need for more reports and "quality" checks to accommodate for bad processes. The business person has good intentions but typically does not have enough knowledge of the end to end processes to offer up proper solution. This is precisely why we should not build what they think they need.

As we all know, IT does not have a great track record for delivering projects on time and on budget. I believe that a major contributor to this is IT's inability to gather good requirements. If we focus the requirements gathering process on business issues and desired outcomes, I believe we give ourselves a much greater chance of success.

What do you think?

Another lesson learned I encountered recently is to clearly define the intentions of your BPM projects. There is a huge difference between attempting to improve processes versus automating processes. First let's discuss the pros and cons of each:

Process Automating in a BPM world

Pros

• Quick wins (unless processes are extremely complex)
• Less culture shock
• Reduce human error
• Start collecting process metrics baselines to analyze future process improvements
• Reduce paper, fax, emails, etc.

Cons

• Only small efficiency gains are realized
  
• Automating non-value add processes
• Missed opportunity to optimize work flow
• May never get a chance to improve processes

Process Improvement in a BPM world

Pros

• Reduce or eliminate waste
  
• Potential huge return on investment
  
• Improve employee performance and customer experience
• Reduce complexity of systems
• Financial justification of process steps
  

Cons

• Potential culture shock issues
  
• Requires more executive support
  
• More expensive to implement
  
• Requires more attention to change management

Like any other large enterprise initiative, a company must have a vision or a roadmap. Some companies may want to achieve financial benefits as soon as possible. For those companies, they should embark on a process improvement initiative right out of the gates. This means that the company must invest in training the business on process improvements with tools like lean sigma, TQM, and others or bring in talent to assess and recommend new processes.

Other companies may want to ease into the culture transformation and start with process automation. This allows the employees to get familiar with the BPM tools and to start collecting data about the current processes (time, costs, bottlenecks, etc.). This information can lead to process improvements down the road. The downside to this approach is that it will take the company much longer to reach the "promised land" of having streamlined and cost effective processes. The real danger that I see is other priorities may take precedence and the company may never get the opportunity to eliminate waste. In my opinion, process automation by itself may not justify the expense of purchasing a BPMS tool. The real value is in process improvement.

Fellow ITToolbox blogger Vladimir Stojanovski wrote a good post on this topic several months ago called Synergies of Process Improvement and Process Automation. In his post he pointed out some interesting statistics that I will mention here:

• Process automation resulting from technology investments yields 2 percent productivity gains. These are the types of projects where technology is used to make old, tired, and broken processes run faster.

• Process improvement through re-engineering yields 8 percent in productivity gains.

• When done together, productivity improvements from both process automation and improvement yield 20 percent in productivity gains.

Mark Smith wrote a post back in 2005 called Process Automation Can Undermine Performance. The key take away from this post is his closing statement:

To succeed at BPM, assess for success, think beyond automation and make performance improvement your number-one process improvement goal.

My point is, the real value in leveraging BPM is process improvements. Process improvement combined with process automation is a powerful combination that can bring real value to an enterprise. Process automation by itself is nice, but it still allows waste to exist in the organization. But whatever your BPM strategy is, make sure it is clear to all team members what the direction is. If some people have an expectation that the goal is automation, while others think the goal is improvement, you will create a lot of unnecessary conflicts.

I wrote a piece called Why are you still generating reports that spawned a few other posts from fellow bloggers James Taylor, Todd Biske, and Robert McIIree. Robert had an interesting point of view which I would like to discuss. In his post he stated:

Excel and similar tools are used for two reasons: first, because it is very familiar to most users and "good enough" to generate reports and analytic output; and second, such use is quick and effective without running through the IT gauntlet to enlarge the effort by "gathering requirements," making it a full-blown project, and waiting a long time for "results."

I agree that Excel is user friendly and a favorite of most business users. Excel is an acceptable tool to manipulate data but should not be used as a system of record. I have seen too many occurrences of key financial data/reports residing on someone's C: drive with no way of validating the integrity of the data. I have also seen many business users create their own "systems" by pulling data out of various databases and building critical reports that are most likely inaccurate. Why are they inaccurate? First, most users don't understand the concepts of data integrity, don't have access to data dictionaries, and don't understand the physical implementation of the data which means they have limited means of validating what they have created is accurate. Second, since IT usually has no idea that these systems exist or how they are updated, changes to the source data are made without the knowledge of the end users' home grown systems. So I say Excel is a great tool for dicing and slicing data but the business community should not be driving the business off of home grown Excel systems.

Further down in the article Robert states:

Instead of asking "What problem are you trying to solve?" we should be stating "Here's what we have available, what is missing or needs to be altered for your needs, and will this work in other parts of the business?" The former question implies that IT knows more about the business and its specific issues than the business does.

Which it doesn't, and never did.

I understand Roberts point but this is where I ask the question, "Are you customer centric or a customer servant?" If you are a mere servant for the business, when they ask for stuff you simply build it the way they want. At the end of the day, you are letting the users design systems. If you are customer centric, your goal is to provide the business with accurate tools while at the same time ensuring that the business processes being requested are value added. One of the main reasons why BPM is so hot these days is that we have been servants to the business for years. The business knows what they need to do their jobs, IT should know how to provide solutions to meet those needs. My company just reevaluated its business processes in a certain area of the business and found that over 50% of the processes were non-value add processes, also known as waste. Why is this? For years the users asked for reports and we created them. The users knew what they needed but they did not ask us to build the right solution, nor should they. Here is an example:

We were asked to create a "data quality check" report to ensure that a certain attribute in a legacy order entry system matched the appropriate value of an attribute in a legacy financial system. The real problem was that the order entry system needed additional quality checks in the user interface to prevent erroneous data from getting into the database. So if I did not ask the question, "What problem are you trying to solve?", we create a new report accompanied by a new non-value add business process which requires manual labor to validate and to correct and does not guarantee that the problem will get fixed. If I do ask the question, I get the answer, "We need to be proactive to find and fix discrepancies between the financial system and the order entry system before we expose bad data to our customers". That response leads us to a simple UI fix which allows the systems to handle the problem and eliminate the need for a data entry clerk to perform more mind numbing, non-value added processes.

I keep going back to Nick Carr's theory that IT does not matter. If IT is simply taking orders and letting the users design their systems, then Nick is right. Instead, IT needs to help the business meet its objectives by delivering feasible solutions that provide quality, ease of use, and business value. If IT's role is to be servants, then there is no reason for the company to have it's own IT staff. Simply hire cheaper labor to follow orders. Just my 2 cents!

I have read a lot of articles recently claiming that BPM & SOA are nothing more then hype. I am here to tell you that if you align these technologies with the proper business case, you can transform your company. I am watching this transformation happen right before my very own eyes. We had an all day future state meeting today and the eighteen people from a cross function of the business were "building the new company from scratch". It was a great moment for me. Just over a year ago, IT sold the business on BPM and SOA. Last week we delivered our first implementation of a BPM/SOA enabled B2B portal. When we did our first round of process reengineering, the company was new to the concepts and skeptical of the investment in the technology. Now, one year later, we have a dedicated architecture team, a dedicated business process department residing in operations, BPM and SOA technology proven in a production environment, and BPM is one of the companies top five initiatives in our four year corporate strategy.

In today's future state sessions, there were eighteen highly motivated and deeply engaged people who believe in the vision and the technology. Our company is transforming from being reactive and heavily labor intensive to proactive and process oriented. We have extremely aggressive growth goals that our existing processes cannot sustain. By using BPM and SOA, we will totally reengineer the way we do business.

At the beginning of the session I explained how SOA will allow us to wipe the slate clean and build our new processes from scratch. I explained in business terms how SOA is the bridge between our brand new business processes and our legacy systems. In our current state findings meeting, there was a lot of concern about "blowing up" all of our systems. In order for us to not constrain our thinking, I thought it was important to start today by explaining that we do not need to touch our legacy systems, instead we simply "connect" them to our business processes with SOA. Below is a slide similar to the one I showed them:



The way I explained it was that in the past we had a separate UI for each one of the systems in the blue circles. Each UI looked different, had redundant data across the applications, and were disconnected from each other. In the new world, there will be one composite UI that is driven by our new business processes and "talks" to the legacy systems through adapters (really web services) while hiding the complexity of all the legacy systems. In other words, they no longer need to care about the order entry system, the accounts payable system, the inventory system, etc. Now they can focus on the process which is designed by the business in the BPM tool and IT can magically connect their processes to our existing systems with a minimal amount of effort (once we built the infrastructure).

Once they understood this, they started building our new company from scratch. It was almost like someone freed their minds and took the handcuffs off. At the end of the day, we had a vision of what our new world might look like and it looks good. No paper, portals, dashboards, workflow, alerts, KPIs, self service, real time data, electronic approvals, etc. That sure beats the sticky notes, emails, phone calls, reams of paper, and rows of filing cabinets. This is all possible because of BPM and SOA. So the next time someone who is afraid to change starts calling the hype card, send him/her this post. Better yet, have them email me. These technologies are the real deal!

Last fall, my company embarked on a business processing reengineering effort that focused on the the sales creation to product delivery life cycle. In just over two months we documented the current state of our business processes, identified the desired future state, performed a gap analysis, identified a roadmap to get us to the desired future state, and built a portfolio of key projects backed by key financial data including ROI analysis and NPV. This portfolio of projects is where we are focusing our BPM and SOA efforts today.

One thing I have been pondering as we get ready to launch our second business process reengineering exercise for another business unit is.....

Is it better to start with the current state and then analyze future state

or

should we focus first on the future state and then analyze the current state processes that are barriers to achieving future state?

There are two reasons why I feel that doing future state first might be better.

1. Focus more on where you want to go and less on where you have been
2. Allows you to start your analysis with the overall business objectives and drill down instead of focusing on deficiencies and working up.
   

It feels like going from current state to future state constrains you when you start defining the future state. When we had business users in the room brainstorming about the future, they would start with the current business environment and start trying to improve upon it. Wouldn't it be better to start with a blank slate and define what the future state should be like without any restrictions? Once that work is complete, we could perform the current state analysis and then figure out how to get from current to future. Granted, some of the future state ideas may not be feasible but why not get all of the innovative ideas out on the table before they are written off?

This is the same approach we are taking from the architecture viewpoint. We are starting with a clean slate. We are establishing a methodology, standards, and best practices purely targeted at a services oriented architecture. Our current methodology is not really built for agile development so why should I try to make it fit for SOA? Our current design standards hardly apply to enterprise wide development. Most of the development we have done before SOA was very application specific. Again, why put a square in a round hole?

I am really just thinking out loud here and not really recommending one versus the other. I have experience starting with current state and moving to future state. We have been successful but it feels like it is a much slower path to the promised land. I would love to hear from those of you who have been through an exercise like this and what your opinions are.

In a previous post (Another Benefit of SOA - Career Path) I talked about how SOA can create a career path that consists of specialized technical jobs.


We just launched the requirements and development stage of our BPM/SOA implementation. We partnered with my buddy Eric Roch and company to assist in the implementation. We brought in specialists for each layer of the architecture. The specialists include a Web Designer for the presentation layer, a Process Analyst for the business process layer, SOA architects, a project manager, and my own architects (Software, Data, Network, and Test) who know the business and the existing infrastructure.

The first day was for introductions, general admin and housekeeping tasks, and a kick off. Today was day two. The first draft of the UI and the business process model was completed today! This was accomplished because we specialized or to put another way, we had experts assigned to specific technologies. My architects are incredible talents but they are not experts at UI development or business process modeling. Had I tried to tackle this internally it would probably have taken us 2 weeks instead of 2 days.

Another reason for the success is that the resources are 100% dedicated to the project and live in a "war room" where they have access to all of the people they need. We bring users and technicians into the war room when needed and never have to worry about meeting schedules. We will also follow an iterative approach and deliver weekly builds so the users can touch and feel the application early and often. This allows us to make changes on the fly and keep the users involved throughout the life cycle.

All that in the first 2 days! I will recap our progress each week and share the good, bad, and ugly as we encounter it.

5. Your consultant's one month contract ends tomorrow and his PC just arrived from desktop services.

4. Your company is rolling out its proprietary CRM solution.

3. There is a large line of people waiting on the fax machine.

2. By the time your new server gets installed it is off of maintenance.

1. Your company buys a 30% stake in a paper manufacturing company as a way to combat the high cost of generating mounds of paper reports each day.

I have read and posted several articles about the many business and IT benefits of SOA. I haven't seen much talk about the benefits it creates for the individuals within IT. This article focuses on the potential career path opportunities that a Service Oriented Architecture can create.

Many IT shops that do not have a well defined architecture have a limited career path for those folks who want to stay technical and not go into management. There are typically a few levels of development (programmer, programmer/analyst, sr. programmer, etc.) followed by an architect role. There is only room for a few architects so most people with over 10 years of experience get stuck in the sr. programmer role for long periods of time. People stuck in this role tend to do one of the following:

1) Go into management soley for the purpose of getting promoted. Many of them return to development, leave, or do not perform at previous levels.

2) Leave due to lack of opportunity.

3) Become miserable and unmotivated

Enter SOA. Companies moving towards SOA may develop a layered architecture like the one in the following picture:

Within each layer you can see specialized roles and job responsibilities. Some of the roles (DBA & Configuration Management) will likely already exist in your organization. Some of the others may be new or the job responsibilities may change dramatically. The point here is that for those organizations with many talented IT professionals who are stuck at a dead end technical career path, SOA might be the answer to your prayers.

Some of these roles (Process Analyst and Enterprise Architect) are best suited for technical folks with great communication skills. These people will interact often with the business. For those who would rather not be exposed to the business, there are many other roles for you (Configuration Management, Object Librarian, Information Architect, etc.). Your more junior developers or people who prefer web development can live in the presentation layer. They will be extremely productive since most of the business rules and services will be available for them to assemble into the UI's. The folks who just love to bang out code can live in the business rule layer where they can develop components and services. The more seasoned developers will build enterprise components and services (i.e. encryption, authentication, error handling, etc.) while the others can focus on application specific components and services (i.e. create order, print invoice, etc.) .

Most IT shops will have pockets of people who don't like change. They may not be interested in these new roles. Those folks can focus on maintaining the legacy systems.

In summary, SOA has many benefits. For IT professionals, many new roles will be created and your company's IT career path will most likely be extended. Over the next few years, more companies will be moving towards SOA and the demand for SOA professionals will be great. So embrace SOA if your company is implementing it. SOA will create many opportunities for those who take advantage of it.

I spent the last two days in Weston, FL. attending various BPM and SOA related lectures. One session I enjoyed was George Paras's "Connecting the Dots: Establishing THE Enterprise Perspective". George is the editor-in-chief for the Architecture and Governance Magazine.

George reminded us that as architects we should think, act, and behave as business people. Everything we do as architects should be geared around value creation by affecting change in the name of product innovation, process transformation, technology transformation, and business transformation. In other words, we need to enable the business to be better, faster, more efficient, better informed, etc.

He then went on to point out that one of the reasons that it is so hard to create business value these days is because our technology and our business processes have become so complex. He showed us one slide that states, "Complexity INHIBITS Change....Complexity consequently INHIBITS Business Value". In my opinion, as we begin to model both our operational and technical architectures, we must make it a goal to minimize the complexity and subscribe to the KISS (Keep It Simple Stupid!) methodology.

The last golden nugget that I took away from George's presentation was about maintaining balance. George talked about how companies struggle to make progress towards establishing an enterprise architecture because the business demands so many tactical projects yielding only short term gains. The chief architect or architecture group must figure out how to get the company to start thinking strategically which yields long term gains. But be careful, you need to strike a balance between tactical and strategic. The business cannot stop while you go off for 6-12 months to create an enterprise architecture.

George's answer to the "Balancing Act" is the Managed Portfolio. The Managed Portfolio combines :

• Enterprise Strategy & Planning
• Project Portfolio Management
• Enterprise Architecture

The leaders of these three groups need to be in sync and must have shared goals geared around value creation.

During a break, I had a chance to speak to George (us Greeks need to stick together). I discussed my project and our approach to implement SOA only for the services required to support our BPM initiative, as opposed to creating a full blown SOA implementation. He agreed that we were on the right path which will make me sleep a little better tonight. I then handed him my last business card which was crumpled and stained with spaghetti sauce. Talk about great first impressions!

There were many other meaningful lectures at the show, but this was the best one to blog about.

How many times have we seen high profile people do things that contradict the messages that they send to us? We have seen a homeland security official stalking teenagers on MySpace, we have seen athletes deny taking performance enhancing drugs only to be proved guilty, and we have seen laws like the Patriot Act, which was supposed to protect us, actually violate our civil liberties. What does this have to do with technology you might ask? Well the lesson learned here is if you say one thing but do the other, the people who follow you lose faith and your initiatives fail.

The same holds true in corporate America. When a visionary leader attempts to implement a culture changing initiative like business process management, agile development, or a new project management methodology, they must practice what they preach. I have seen several attempts to implement standard software methodologies, like CMM, fail. Why do they fail? Because the visionary leader didn't practice what he preached. In this example, the visionary preached that by adopting CMM, IT would be more successful in delivering projects. Unfortunately, implementing CMM was not carried out like a project. No scope was defined, no communication plan was developed, no stakeholders or executive sponsor was named. Instead , a boat load of documents were thrust on the IT staff. Of course, there was mass resistance and the initiative failed. Had the visionary practiced what he preached and used CMM to implement CMM his chances for success would have greatly increased.

Practice what you preach applies to those trying to implement SOA for the first time. You probably sold management that some of the advantages of SOA are speed to market and agility. The CEO was so excited by your presentation that he freed up a boat load of funds to launch your SOA initiative. Guess what? It's now time to get agile. Practice what you preach. Throw away your old waterfall approach. Gone are the days of 6-8 month deliverables. Start delivering early and often. If you don't change your ways, the CEO will quickly lose faith in this initiative quicker the you can say WMD.

If you are one of the many enterprise architects who have great visions of what SOA can do for your organization, but can't find anyone in the organization to provide the financial support needed to bring SOA to realization, listen to this real life story of how you can get the business to go to bat for you.

A medium sized company, who will remain unnamed, was supporting a sophisticated, proprietary supply chain system that was taking an army of developers to keep it running. The business was changing rapidly and the demands for new features and enhancements were far exceeding development's ability to meet the customers' needs. The system was several years old and needed to be integrated with several other silo legacy systems. The UI was not user friendly and was in dire need of workflow capabilities. The business wanted something to change but did not want to sign up for another long painful rewrite. So IT turned this liability into a win-win proposition for both the business and IT. Here's how.

First, IT put together a cost/benefit analysis for only the IT side of the equation. There was a huge opportunity to reduce the amount of resources required to maintain the legacy system while providing business value by improving speed to market, increasing new development capacity, and improving quality. When presenting their findings, the IT group pointed out that they thought there were even more substantial opportunities on the business side of the equation if the business would evaluate their existing, 20 year old processes.

After convincing key executives in both the business and IT that a large opportunity existed, the business funded the first phase of this initiative and brought in an outside firm to perform a business process analysis. In just 90 days, the current state and future state business processes were modeled and a few compelling opportunities were discovered. What the business discovered after interviewing numerous people throughout the organization, including several customers, was that their existing processes where not only costing more then twice of what the future state would cost, but they were potentially limiting the company's ability to create more sales.

At the end of this phase, the major IT and business stakeholders held a future state design meeting. In this meeting, the business discussed specific use cases that they needed in the future state that would allow them to reduce costs and increase revenue. For each use case, IT would describe the technology required to satisfy the use case. The use cases contained items like wizard based data entry forms, visibility into orders, B2B web interface, operational reporting, and integration with several legacy systems. IT was able to map those use cases to a BPMS/SOA solution to create a robust, user friendly, workflow system that could be deployed rapidly without rebuilding years of legacy systems. What the business heard was BPMS and SOA would answer their prayers.

The next step was to sell the CEO and his leadership team on how the company could be transformed by reevaluating its business processes and applying BPMS and SOA to help the business achieve its goals. It was the business and IT, hand in hand, selling this idea to the executives. The sell was easy and the company has moved on to the next phase with sufficient funding and executive level support.

I know this was a long story but here is the point. The IT team knew for 3 years that a BPMS and SOA solution was the answer to the problems that they faced each day. But IT had not figured out how to sell it and how to fund it. Finally, the pain became so great that IT realized that they had to figure out a way to sell these concepts to the business. First they showed that the cost/benefit just in IT was substantial. This got people's attention. Once they got people's attention, they were able to engage the business and gave the business ownership of transforming the company. Once the business had bought in, the rest was history. So what is the moral of the story? Aligning technology with real business cases increases your ability to sell technology to those who write the checks.