The move to SOA and BPM means that application development can be more modular. But data is the essential foundation.
BPMInstitute.org:
You are now out on your own. What does BizThink do?
Fletcher:
We have a unique offering which involves process redesign and SOA and BPM implementations as part of a concerted effort. There are people who can implement BPM applications and there are people who can do process design but there are not many firms who do both equally well.
BPMInstitute.org:
What is your methodology?
Fletcher:
We found that you can’t really start with the technology side of the house. First, business has to lead and invest in the projects. Second, the most successful projects are those in which process redesign was done up front, not as part of an implementation. Finally, we have come to understand that big-bang projects don’t work very well either.
BPMInstitute.org:
Why?
Fletcher:
A $5 million or $10 million project inherently carries a lot of risk, and a lot of coordination and consensus building. A $250,000 project is not as risky, and involves fewer external dependencies.
BPMInstitute.org:
So what is the alternative?
Fletcher:
Though we work with big companies, we pick a single process in a single line of business and we do process redesign just on that process. It is a proof of concept, an evangelization platform and cost-effective. If you do the process redesign up front and do it correctly, you usually get a hard dollar return in the course of the first project.
BPMInstitute.org:
Can you give me an example?
Fletcher:
In one project, the key metric was a cycle time of a given process. When we started, it was at 18 days. After 10 weeks, when we finished, it was down to 4.5 days. And there were all kinds of ancillary benefits. Customer complaints went from the high dozens to zero. Since cycle time was reduced, people weren’t mad any more and they were not complaining. Employees were happier because they were not being yelled at by customers all the time.
BPMInstitute.org:
Sounds good. Then what happened?
Fletcher:
Six more projects were lined up after that. And when you do the process work up front, doing the application becomes more of a paint-by-numbers exercise.
BPMInstitute.org:
How so?
Fletcher:
When it comes to the implementation of technology, the tools work now, so we spend less time opening cases with vendors. Because of the process redesign work done up front, we know exactly what the application needs to do because of the great process work done up front. You take a lot of the risk out.
BPMInstitute.org:
You frequently talk about the importance of the data layer in BPM and SOA projects. What is the significance of the data layer?
Fletcher:
One of the first major SOA projects I worked on failed. I was the architect of the application. We were doing a federated portal and the presentation layer worked flawlessly. The SOA layer worked perfectly. But it was built on old operational data stores with more than 40 incoming feeds and corrupted business logic. After nine months in production, it had to be turned off because the underlying data was so flawed that it was unusable to the end-users.
BPMInstitute.org:
What was your take away from that experience?
Fletcher:
We were flawlessly and effortless sending out the world’s worst data. It didn’t matter that the pages were returned in three seconds or that the Web services worked 100 percent of the time and the platform never went down. It was still unusable to end-users.
BPMInstitute.org:
How do you avoid that kind of stumble?
Fletcher:
People who start these projects tend to think of SOA or an enterprise service bus as core infrastructure to the organization and try to leverage it across multiple organizations. They become big implementations. The net effect is that they put in an ESB for a whole line of business or sometimes for the whole enterprise rather than serving a single project. The problem with that is you end up putting in a lot of external risk factors. You end up integrating with up and downstream systems of record. They become necessary parts of the project, but that adds significant risk.
BPMInstitute.org:
What do you advise?
Fletcher:
BPM and SOA are something that every organization is going to have to move towards at some point. The technology is too compelling and the ROI numbers are too compelling. And the tools actually work now. There is no reason not to do it. You almost have to it. But you should start with a smaller project.
BPMInstitute.org:
In addition to the risks factors in larger projects, why start small?
Fletcher:
There is a culture-change aspect to implementing either a BPM platform or an SOA platform. It requires a shift in thinking in how the developers and architects approach developing applications. They are doing different things and using different tools. And these technologies present the opportunity to do development in a new way, with agile development and iterative development methodologies. It’s important to start with a manageable project. Culture change rarely happens effectively with big-bang types of projects. Better to start small and incubate.
BPMInstitute.org:
What is the incentive to tackle changing the culture?
Fletcher:
The business value proposition of these iterative development methodologies is very compelling. The business side does not just want a BPM platform. They want the development methodologies that come with it. They want the better time to market, fewer defects, better visibility and control. All those are critical to the business.
BPMInstitute.org:
What role will the technical groups play?
Fletcher:
Developers become architects. If you make an analogy to building software and building buildings, it used to be that you would bring in bricks and cement and a craftsman would lay bricks, one brick at a time. Now, buildings go up in huge chunks. They bring in entire walls prefabricated. The buildings are much more modular than they used to be. You can’t change a wall in the old-style buildings. In the new style buildings, you can mix and match as you want in terms of how the floor space is being utilized. If you want to lay fiber optics in an older building it is a chore. In a new building, you can do what you want to do.
BPMInstitute.org:
And with software applications?
Fletcher:
It used to be that you built software applications one line of code at a time. Craftsmen were doing it. Now software applications can be built using a prefabrication method, just like buildings are prefabricated. The prefabrication is being done by the tools.
BPMInstitute.org:
So developers become architects. What do they do?
Fletcher:
Architects will spend more time creating registries of services, ensuring there isn’t unnecessary duplication, ensuring that the underlying tools and platforms are being utilitized maximally, etc. Developers will spend less time writing lines of code, and more attention will be focused on reusable interfaces, and overall enterprise stability and performance.
BPMInstitute.org:
So let’s circle back. What role does data play in this modular approach?
Fletcher:
No building is any good without a good foundation. It does not matter how well you have built the walls and how perfectly you have met the expectations. If the foundation is not good, it will fall apart quickly. Data is always the foundation of applications. It has to be considered first. It has to be done first. You can’t go back and redo your database architecture after the fact. It affects everything upstream. Your data access layer, your services layer, your user interface changes based on the data. If that is not done correctly first, sooner or later everything falls apart.
BPMInstitute.org:
For people who have not started with BPM and SOA, what will motivate them to get started?
Fletcher:
The number of people planning SOA has grown exponentially. The value proposition of SOA is obvious. Still, there is a lot of skepticism. We need more reference projects with the hard ROI numbers. We need more substantiated anecdotal examples. And, the initiatives are going to be led by the business side. They are not going to be led by IT. As part of the project, business has to communicate business requirements that involve iterative development, governance and registries.
