Combining BPM And SOA... What's All The Fuss About?

There has been a great deal of discussion around the combination of Business Process Management (BPM) and Service Oriented Architecures (SOA). Just run a search on these terms and you will see hundreds of articles and blog discussions on the joint topic. Many pundits believe that BPM is the real-world manifestation of SOA, which tends towards the theoretical. Check out this ITBusinessEdge article for a discussion. What is clear is that while one does not rely on the other, their individual value is greatly enhanced when joined. Review my post on May 3rd for a discussion on BPM.

While many BPM systems are focused on human-human flow of work, advanced suites can leverage SOA and Web Services to invoke systems as part of a comprehensive business process. By combining the two, a holistic process can be achieved.

For example, in the Financial Services scenario from yesterday, a new loan application is faxed into the organization. This fax invokes the BPM system and the specific business process associated with new loans. A SQL task in the process is kicked off and executes a database query to see if the applicant is already a customer, to ensure no duplicate accounts. Once it is determined that the applicant is not a duplicate, another step in the process connects with the mainframe and returns an application number to the business process. From this point, a business rules engine is called through a SOAP Web Service to evaluate the details of the loan application and depending on the outcome, approval may be automated and the BPM system notified. The next step automatically seeks the loan officer's review and final approval. Once recieved, another step automatically sends mail notification to the applicant, informing him/her of their approval.

This is a greatly simplified instance of the BPM system managing just one business process, making "calls" out to other systems and seeking human input along the way. With a Service Oriented Architecture, the details to making this process work are simplified. Now imagine hundreds of processes much more complex than this - traditionally static processes in an ever-changing business environment. Many of these processes are created by different departments with limited resources and different individuals with varying technical ability. While SOA, with its central "repository" of services, and traditional BPM controlling the process, makes great strides in managing the flow of work, ensuring efficiency and consistency. The dynamic business environment means that ongoing process optimization and adaptability is incredibly important, particularly to ensure a competitive edge.

More on this soon.

SOA In Practice

Now that we've got the theory, jargon, and general technical aspects of SOA out of the way, let's explore an example of usage. My hope is that this may spark some ideas for you in your organization.

Scenario Background: A regional Financial Services company was seeking to expand the average number of products purchased by existing customers. They knew the more business each customer conducts with them, the greater the impact to the bottom line, and the greater the retention rate. They launched a broad-spectrum marketing campaign, including print, radio, and television advertising. They even included Internet-based marketing in the form of Web advertising and e-mail campaigns. As a result, there was an influx of inquiry from both new and existing customers seeking to setup a variety of accounts. Applications came in from all channels (Web, paper, phone, even e-mail).

Challenge: The challenge for this company was in quickly processing these applications and creating the new accounts to meet high customer service expectations. As part of this, it was important to ensure that there were no duplicate accounts - these wreak havoc on their systems, especially invoicing and billing. Furthermore, since many of these were loan applications, they required credit scores which had to be obtained from a 3rd-party.

Before SOA: Prior to implementing SOA across the enterprise, each system and division had its own unique forms for new accounts, which were inconsistent. Often little differences would cause glitches (e.g., Male/Female vs. M/F, date formats, etc.). In addition, the 3rd-party providers for Credit Scores were different, depending on the department (e.g., Mortgages vs. Auto Loans). A constant challenge was in checking for duplicates, because the systems setup for this task often failed due to communication protocol errors. Checking for duplicates slowed the amount of time to process a new application.

Using SOA: With the newly implemented and fully tested SOA-based setup and associated Web Services, this company met their performance targets. Here were a few key benefits:

• Forms - rather than have disparate forms, with inconsistencies, they created a central repository of forms and "snippets" of forms. They used Web Services to call these forms when creating a new application. If anything changes on these forms, rather than having to make the change in 50 different places, it is updated only once, and then pulled when needed.
• Credit Scores - for consistency and speed, the firm made a decision to consolidate 3rd-party credit-score providers to a single company. They made sure the selected provider offered a secure, Web Services interface, with high availability, to which they could connect their loan application system and automatically capture the credit score. This reduced errors and increased efficiency.
• Checking for Duplicates - they used Web Services to connect to their mainframe, which houses all customer Account Numbers. Rather than taking a great deal of time and resources writing code, figuring the format, establishing communication protocols, etc., they easily called a Service to identify duplicates. If no duplicates were identified, the system called another Service to setup the account number. By calling a central service, consistency and accuracy were preserved.

There are an infinite number of possibilities for leveraging a Service Oriented Architecture. However, Business Process Management and SOA, are particularly well-suited to one another. I'll explore this powerful combination tomorrow.

Working with SOA

On Friday I discussed what SOA is and why your organization should be looking into it. Today, I will explore the real-world of SOA. Referring back to the "electrical outlet" example outlined in Friday's post, even 102 years since the 1904 invention of the "electrical plug and socket" by Harvey Hubbell, while standards exist, there are still 14 plug and socket types used across the globe. Anyone who has traveled to Europe with an electric razor, sans adapters, has learned this the hard way. Likewise, having a Services Oriented Architecture across line-of-business (LOB)applications does not mean perfect interoperability, but it is a significant improvement over the alternative - writing C-code, developing communication protocols, designing error handling etc.,

While SOA can be implemented using any service-oriented technology, Web Services is the most common. Example Web Services include SOAP and REST (to delve deeper into these services and related SOA technologies, select the hyperlinks in this post). Web services allow communication between software, based on a set of standards (e.g., XML, WSDL, UDDI, etc.). It is also important to note that with Web Services, software applications do not need to be based on the same platform (e.g., Windows vs. Linux) or same programming language in order to communicate. These issues have long been the achilles heel for enterprise systems.

Organizations that have adopted SOA are primarily focused on communications between systems within the company. However, Web Services ushers in a whole new set of capabilities by allowing for smooth interoperability with applications outside the enterprise. While potentially revolutionary, this is less common as significant security, accessibility, and performance issues remain.

Tomorrow I'll review a business scenario that leverages SOA to drive value to the bottom-line.

SOA And Why You Should Care

A Service Oriented Architecture (SOA) is "a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within a distributed systems architecture." Think of a "Service" as application code that performs a specific task or set of tasks (e.g., determine a credit score for a loan applicant). These discreet services can interact in a standard way so it is easier to link one service to another.

Imagine if each appliance in your house were connected to your outlets using a different plug, and the outlets were different as well. Just getting your toaster to work would be incredibly frustrating, requiring numerous adapters and connectors that would be prone to failure, loss of function, etc.. This is the environment that IT professionals must deal with in their enterprise software infrastructure. The advent of key technologies (those that compose SOA) and development of industry standards have essentially made interaction between systems and applications easier and more straightforward.

Here's the upshot:

• Significantly reduce application development costs
• Increase business agility because useful pieces of code in one part of an organization no longer need to be constantly re-written... they can now be easily re-used
• Design completely new applications with minimal effort by leveraging code from a 3rd-party and combining it with existing code
• Create competitive advantages where no one is looking through a creativity and a just a few lines of code
• Reduce the time-consuming and risky task of changing firewall filtering settings by utilizing HTTP with Web Services

Next time I'll explore how it works, followed by a post with examples.

What Does SOA Mean For Your Business?

For the past two years the popularity of Service-Oriented Architectures (SOA) has been steadily increasing. Just check-out this Google Trends report. This begs the questions:

1. What exactly is SOA?
2. Why should one care?
3. Is SOA just marketing hype?
4. Is SOA just for technical-types? What does a business person need to know about SOA?
5. How does SOA benefit one's business?
6. How should one get started implementing a service-oriented architecture across an organization? What are the pitfalls?
7. Who benefits most from SOA?
8. How will SOA impact my existing infrastructure and business processes?

Over the next few posts, I hope to address these and related questions, providing greater clarity into a complicated issue with this new architecture.

What's The Deal With Buyouts?

On April 3, 2006 Global 360 was purchased by TA Associates in a $200 million management buyout (MBO), as announced in this press-release. Why am I talking about this when it happened over a month ago? Two reasons:

1. I continue to get asked about the nature of this transaction and the differences between the types of private equity buyouts.
2. Buyouts have been extremely popular and continue to grow

First, what are the different types of buyouts? A buyout is executed when either the controlling stake or the complete company is sold. There are two basic flavors: Management Buyout (MBO) and Leveraged Buyout (LBO). An MBO, often referred to as "going private," exists when a company has its outstanding shares purchased by an individual or small group of investors in order to obtain complete ownership. In the case of Global 360, when Sonny Oates, the primary owner, decided to retire, he executed an MBO with TA Associates, Technology Crossover Ventures and JMI Equity. More on this in a moment.

An LBO is a takeover that occurs primarily through borrowed money (typically greater than 70% of the total purchase price) often using the company's own assets as collateral. An LBO is often viewed as a desperate transaction, used to prevent hostile take-overs, or ensure a company's survival in rough times. LBOs were made famous during the 1980's.

A February 2006 article in the Washington Post captured the trends in "private equity dealmaking." Here are a few key facts (from the article):

• Private equity firms struck deals worth $396 billion in 2005, a third straight record year and a 51 percent increase over 2004, according to Thomson Financial _ outstripping a 39 percent rise in overall mergers and acquisitions business.
• In 2005 buyout houses raised $261 billion in new investment...an all-time high
• Overall, take-private deals rose by more than 150 percent worldwide to $97.4 billion, beating the previous record of $85 billion in 1988
• The growth of buyouts is widely blamed on the burden of Sarbanes-Oxley legislation and increased shareholder litigation risk

So what is the impact of the MBO on Global 360 and its customers? Very positive. This is for many reasons, not the least of which is the instant improvement to the Global 360 balance sheet, giving us access to the capital for growth and acquisitions. In addition, the management team and vision remain in place, only with greater resources for execution. This is because TA, TCV, and JMI have no interest in managing the company, as evidenced by their 28-year investment history and portfolio. In a market ripe for consolidation (as described by Gartner), this buyout ensures Global 360's independence and leadership position.

For more information on buyouts, checkout the always interesting "Buyout Blog."

Implementation Approaches, What's The Difference?

While I have talked in the past about the attributes for successful projects, I did not discuss the tactical approaches. Before joining Global 360, I had not heard much talk about tactical methods. However, it is obviously quite important. In my research, I have deduced the approaches down to the three most common: Agile vs. Iterative vs. Waterfall. What follows is a short discussion.

Agile Methodology
Back in 2001, a group of software developers who followed the "lightweight method [of development]" gathered in Utah to discuss various development methods. Out of this meeting, they crafted the "Manifesto for Agile Software Development." Essentially, it boils down to this (from the Agile Alliance Organization):

While all of the following are important, the Agile Method values:

• Individuals and interactions more than processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The ultimate end-goal is a successful implementation of working software. The most common criticism of Agile methodology is typically that it sacrifices detailed documentation for face-to-face communication and efficiency. The best way to think of the Agile Method is as an adaptive approach. In other words, as a project's needs change, so will the team - in order to deliver what is ultimately desired. This is not to say that the Agile Method is unplanned, rather it accounts for the reality where software implementations are often a moving target. Critical to this method, more so than any other, is the experience and resumes of the people involved.

Waterfall Methodology
Proposed in 1970 by W.W. Royce, famed software engineering researcher, this approach views development as a flowing process of: requirements analysis, design, implementation, testing, integration, and maintenance. Only when one step is completed and perfect, should the next one begin - there is no jumping back-and-forth, or skipping around. Interestingly, in the same paper which introduced the concept, Royce argued against it saying, "[it] is risky and invites failure."

While on paper Waterfall Methodology makes a lot of sense and in certain cases is ideal, most organizations are unable to invest the resources (i.e., money, people, time) required for a successful implementation of the method. In fact, many organizations do not know exactly what they want until they have a mock-up or prototype. They then use this as a way to learn more and incorporate the positives and eliminate the negatives in their design.

This is summarized quite nicely in a Wikipedia article on the subject. It states:

"The idea behind the waterfall model may be "measure twice; cut once", and those opposed to the waterfall model argue that this idea tends to fall apart when the problem being measured is constantly changing due to requirement modifications and new realizations about the problem itself. The idea behind those who object to the waterfall model may be "time spent in reconnaissance is seldom wasted."

Iterative Methodology
On the scale of "adaptive" to "predictive," this method falls somewhere in the middle between Agile and Waterfall approaches respectively. Essentially this approach allows for incremental development where a developer learns from previous versions of a system, using this information to constantly improve each new release. While quite practical for software development, for project implementations, it is not quite as applicable.

The Iterative Method boils down to the: Initialization step (creating a base version), the Iteration step (redesign and implementation of Project Control List tasks), and the Project Control List (record of all tasks that must be performed, including new features).

The initialization step forms the foundation for the project, offering the core features to solve the problem. It is usually easy to implement and simple to understand. The idea is to then use this as a way to elicit feedback from others. This feedback influences the Project Control List, which is used to form the next iteration.

The Value for Symetra

In yesterday's post, I described Symetra's phased approach to implementing their Business Process Management system. No matter how smooth the implementation, the bottom-line benefits must be there. So what are their results to date?

• Increased application processing capacity by 30%
• Reduced application processing time by over 3 days
• Decreased the need for temporary staff
• Faster and more effective customer service
• Shortened the time to train employees
• Improved employee satisfaction by making them more efficient in their activities
• Increased the ability to respond to process changes related to business strategy

In addition, they are no longer in constant reactive mode, "putting out fires." Now, goals are driving the process through the automatic work assignment. To learn more about Business Process Management and how your organization may benefit from a BPM solution, check out BPMInstitute.org, an independent resource for BPM information.

You've Got Goals, But Are You Meeting Them?

Last Thursday, Symetra Financial's (formerly Safeco) Margaret Harder spoke at GCC. What was particularly interesting was her in-depth description of how their Global 360 BPM Suite has enabled them to process more work, in less time, with fewer human resources.

Based in Bellevue Washington, Symetra has over 2 million customers and 200 employees, managing $20 billion in assets. They saw 14% growth from 2003-04. Incidentally, their initial Global 360 installation was back in 2003 and was designed to move them away from paper. Then in 2005, they expanded the system within the organization and in terms of capabilities. The Customer Service department implemented the process components to achieve true Business Process Management (BPM).

In just 5 months from start to finish the system and associated processes were fully implemented. As part of the implementation, they established measurable goals for 58 different transaction types. They incorporated these goals within the system such that the established parameters and thresholds would be automatically managed. This would mean that as tasks flowed into a queue, based on these parameters, it would be proactively assigned to the optimal resource. Those with permissions can run real-time Goal Management reports to determine efficiency and effectiveness in meeting the established goals. Their next step will be to incorporate Business Optimization into the setup.

Since Margaret's team recognized the importance of this system to the organization, they wanted to ensure a smooth roll-out. This meant smoothing the shock that is often associated with change, especially when tenured employees are affected. So they introduced these changes first with a pilot group of just 8 Customer Service Representatives. After just a couple of days of working through the kinks, they began to see significant benefits. Excitement started to spread within the group, but they were careful to manage the enthusiasm. They continued to roll out the system in ever larger groups, while:

• Sending "benefits" e-mails to the broader organization
• Placing creative posters around the building that described individual benefits
• Collecting and posting testimonials of pilot users
• Establishing a "mentor" program between existing and new users

All this was completed to ensure a positive transition. After a total of 4 stages, they completed the roll-out and instead of "shock and awe," by that time the introduction was barely noticeable... exactly how they wanted it. So how are they doing, and what are the hard and soft benefits? Check back tomorrow for details.

Managing The Distributed Workforce

Every organization must plan for a variety of risks. As I mentioned in my post on 4/26/2006, it is often the act of planning that matters much more so than the plans themselves. Continuing from yesterday, I am particularly interested in AIG's distributed workforce and thought you might be as well.

A distributed workforce is like the internet versus a mainframe. In fact, the development of the Internet began as part of wartime communications. The defense department was looking into the ability to re-route digital traffic around failed nodes – an Achilles heel for the then current phone network. With such a network, if a portion failed, another node would pick up the slack.
In the event of a disaster, a distributed network is an ideal way to handle the situation. The human brain acts in a similar way. In many cases, as one sense fails (e.g., sight), another compensates (e.g., hearing), becoming more acute. While certainly not perfect, it provides the strongest chance for survival.

With the progression of telecommuting and its enabling technologies, a distributed workforce is more practical than ever. While certainly not every organization can support such an organization, those that can may want to seriously consider it as part of disaster planning. So how do you sustain such an environment?

I asked Mr. Popolano, AIG’s CIO this question. He suggested that monitoring is key. A remote employee’s progress and efficiency should be transparent – both you and they should be able to monitor it in real-time. Goals should be established and actual results compared. If an employee is consistently falling short of defined goals, action must be taken. An employee who is just incapable of success as a remote contributor must be dealt with. He/she must be prevented from becoming a “virus,” negatively influencing fellow remote co-workers. Done well, a distributed work environment can improve employee satisfaction and productivity, while being an important component to handling all types of disasters.

What's AIG Worried About?

After speaking with a few customers, I realized the timeliness and importance of Tuesday's GCC presentation by AIG CIO Mark Popolano. He gave tremendous insight into how valuable BPM really is and why it is critical to growing business.

AIG is one of the largest insurance providers in the world (#9 in Fortune 500 ; 2005 sales = $109 billion). They have over 95,000 employees with 11,000 employees in IT alone. They have a 100% virtualized help-desk, supporting over 2,700 applications, along with 30,000 agents who helped generate $10+ billion in Net Income for 2005. Amazingly, they now have more than 40% of their workforce working from home – talk about distributed work environment!
In the short time they have been using Global 360’s BPM system, they have been able to:

• Optimize business processes across the organization. According to Mark, “the business process is the end-game…[you must] keep the flow of work through your organization to keep the cash engine going.”
• Eliminate compensating controls, which is critical for compliance with Sarbanes-Oxley legislation
• Enable a mobile, dynamic, workforce whose productivity has increased along with job satisfaction, and retention
• Reduce risk associated with an exclusively bricks-and-mortar operation in the event of a disaster
• Reduce costs by enabling effective outsourcing

Interestingly, Mark spoke quite a bit about their concern over the avian/pandemic flu. In the event of the avian flu reaching the US and becoming highly contagious between humans, chaos could set in. He knows, however, that AIG must continue to operate in the face of tremendous adversity and serve their customers. According to Mark, their BPM system enabled AIG to be “up-and running just 9 hours after hurricane Katrina,” ready to be there for their customers. If they fell victim to chaos, amongst other detrimental effects, they would put their brand and reputation at risk.

A key component to addressing risk is through a distributed workforce (PDF).

BPM – Deja Vu All Over Again?

You would not be crazy if you thought Business Process Management (BPM) was just Workflow repackaged in a 21st-century Analyst-provided moniker. [Adding to the confusion, BPM is also often referred to as Business Performance Management.] In today’s post, I’ll attempt to provide some clarification on how Business Process Management is more than just Workflow with a fancy name. Today’s GCC discussion with Gartner Analysts, Jim Sinur and Michael Melenovsky was quite insightful. However, if we look to the Analyst community for clarification, well… there is little agreement. We at Global 360 consider BPM the act of managing and routing content within or external to an organization, while regularly modeling, analyzing, and simulating existing and alternative flows to optimize those processes and meet pre-defined goals.

While there is certainly overlap, workflow falls short of the second part of the BPM definition. I think of BPM as the logical evolution of Content Management and Workflow. Why? Well, most workflow systems are limited to routing content/work items (e.g., insurance claims, new loans, expense reports, address forms, etc.) in a static flow. But what indication do you have that an existing flow is the optimal route? What if there were another way… a better way. That is where BPM comes in. Like an experienced taxi driver who knows how to get you to the airport on time, even though all the major highways are blocked, a true BPM system can provide you visibility into your workflows and help you determine the optimal route to meet your goals. Better yet, it can use this information to automatically and proactively route content based on pre-set parameters and goals. Workflow tends to be stagnant –once setup, a route will rarely change, because it was never meant to.

In today’s dynamic, highly-distributed, work environment where margins are tight and change is constant, routes are never done. Like animals in an ecosystem, organizations that can adapt the fastest will have a tremendous competitive advantage that will directly impact the bottom line. Content is no longer king, Process has taken the reigns.

The Chicken Or The Egg - Starting A Project

Yesterday I wrote about the negative effects of the barriers between the IT and Business communities. Interestingly, while here at the Global 360 Customer Conference I noticed a dilemma addressed in almost all customer presentations… who should be the impetus for application development: IT or Business? They all had the same answer – it depends.

While this indecisiveness may seem like a cop-out, it does depend, but that should not matter. Oftentimes, as IT implements/develops, tweaks, and maintains systems, they determine creative approaches to addressing inefficiencies within the business. But it is all too common that when they present solutions to problems unknown by the business community, they are dismissed. Those who are already too busy firefighting can be frustrated by those creating problems where none were thought to have existed. An organization’s culture should foster and embrace a proactive approach to addressing problems and making improvements. After all, isn’t that what Six Sigma, TQM, etc. are all about?

Conversely, the business community should always be seeking improvements across the organization. A tweak here and a tweak there can mean the difference between growth and stagnation, beating your competition and filing for bankruptcy, customer loyalty and defection, etc. IT must embrace these changes/suggestions, but like their counterparts, they are often too busy. The solution is a corporate culture that empowers and supports ALL of its employees to seek out improvements. Of course not all ideas can be implemented, or are worth it, but all should be given proper consideration and due diligence. If not, the competition will.

Breaking Barriers - Mending IT And The Organization

There is a disconnect between technology users and technology implementers. While I do not have hard data as in my other posts to back-up this claim, I have noticed it all throughout my career, from my IT work to Management Consulting. I suspect you have noticed also. Even today, it is always interesting to me when I am speaking with technology leaders and ask to meet with the user community, or vice versa. I am almost always met with apprehension. This rift is dangerous, especially as enterprise software becomes more complex and integrated. It is time to make amends. Why?

Last week I spoke about what it takes to have a successful implementation. Communication, expectation setting, understanding needs & requirements, were all at the top of the list. The irony is that these tend to be executed poorly in implementations. I dislike stereotypes, like “techies are introverts with no people skills,” not only because at best, they are wrong, but because they relieve both sides of critical responsibilities. The one who is stereotyping puts up a barrier and fails to understand the individuals who meet their perceived stereotype. The one being stereotyped can use it as an excuse or a crutch for poor behavior. I believe stereotyping is a core contributor to this ongoing rift. As systems continue to grow in complexity, it is becoming more dangerous. Logically, however, it makes no sense.

The purpose of IT is to serve the needs of the business, whether automating repetitive tasks, streamlining complex processes, or developing new business channels as in self-service. How can those implementing these activities do so without working with those who need them? Everyone would be better served by thinking in terms of the Vendor/Customer relationship, where IT is the vendor and the user is the customer. Any vendor knows to maintain a happy, loyal customer, one must first understand the needs and wants of the organization. Business users would be well served by understanding the capabilities and resource availability of their internal IT teams and related personnel. As with most activities, expectation setting and communication on both fronts are imperative. Those organizations able to overcome stereotypes will most effectively complete projects, meeting expectations on time and on budget. This will provide a distinct competitive advantage over those enterprises unable to make amends. Stereotyping is always a bad idea.