Service-Oriented Architecture

SOA transformation is all very fine, but does is apply to all situations? For example, how do you apply SOA principles to organizations where the multitude of desktop users love the spreadsheet interface and swear by it? Perhaps a better question is, how should you apply SOA principles to environments where users are not looking to share information between desktops, where the ultimate flexibility of your own personal spreadsheet is inherently the differentiator between your product and your competition's, and where SOA is looked on as "Simply Over Ambitious?"

The finance world lives in spreadsheets. And, to give Microsoft due credit, they have marketed a whiz-bang product with Excel. A large percentage of financial models exist in spreadsheets, and they drive the financial products offered by multinational financial institutions. Sharing of information is primarily a matter of sharing a common repository of large files.

So where is the nail for which we have the SOA hammer? While the complex logic of modeling risk and other aspects of financial products is addressed by Excel, the volume of files is becoming an isurmountable problem. Plus, there is no real security for access. This was not a problem when the entire spreadsheet was handled by a small select team; but that is not applicable anymore. Errors and bugs are very hard to track. And cut and paste errors abound.

I faced this very situation at one of our financial clients. The client originally engaged another consulting firm to provide a solution to these problems. A grand SOA vision was drawn up. After about a year, the client lost patience, and were especially peeved when they saw the first deliverable about 12 months away. So they scaled back and asked for something small. That was when they engaged us.

SOA in the small? It is a kind of paradox. However, the real question to ask is, where is it truly applicable in this scenario? The answer is - "data management." Data from several disparate systems makes its way into the spreadsheets. This data needs to be standardized, cleansed, and integrated through common meshanisms. But wait a minute. Is this not an EAI problem? Where does SOA come in?

The very basic services under the SOA umbrella are foundation services. These basically include data gateways and the like to enable consumption and querying of data. Providing these services as a layer above the native integration with systems like Bloomberg allows the middle tier systems to make them available for consumption by spreadsheets. Once the services are built, they can be shared by trading systems that need the data for transactions.

 This is definitely "SOA in the small." And it doesn't even go into the aspects of organizational governance. Nevertheless, it prepares the framework for departments to participate in the larger SOA initiatives that are already in inception across the whole organization.

Posted by Ajit Sagar at 11:46 PM | Permalink | Comments (5) | TrackBacks (0)

In recent years the BPM space has evolved significantly. During the past 4 years BPM license revenue has grown nearly 100% yoy. As per leading analysts firms, BPM is the next big wave of the IT industry. Currently over 50 vendors claim to offer BPM suite that would transform clients business by making the systems agile. However, the reality is that many enterprises, and even product vendors, are focused mainly only on Business Process Modeling rather than having holistic approach for entire BPM lifecycle.

I think the main reason why process modeling stimulates a lot of excitement, while complete BPM lifecycle gets less emphasis is due to the fact that process models are tangible artifacts that both business and IT can very much relate to and the gains can be quickly realized; while on the other hand, implementing complete BPM solution can be quite overwhelming and the value realization has much longer gestation period.

Process Modeling is definitely a very critical phase of building the BPM solution, however the full value from BPM is realized when the business is able to manage the performance of business processes.

Implementing a BPM solution involves externalization of business process flow logic and frequently changing business rules (such as tax computation, discounting policy, credit approval rules etc) from cryptic computer code into language that business users can understand. This enables business users or semi-technical personnel to quickly change the process flow and business rules to adapt to the changing market needs, making the systems agile.

Another very critical aspect of a BPM solution is Business Activity Monitoring (BAM), which includes systems & infrastructure that enables monitoring and analyzing business performance. This provides critical insights into the real impediments in business performance and providing vital clues for optimizing business processes.

Implementing the complete BPM lifecycle - from process discovery & modeling to business activity monitoring, analysis & optimization – enables the enterprise to continuously optimize their business performance.

Most of the CTOs, Enterprise Architects and IT Managers that I have had the opportunity to collaborate with share the above views. But the real challenge is how a large enterprise should plan their BPM journey that encompasses the complete BPM lifecycle from modeling to monitoring. From my experiences I have learnt following lessons that make implementing the complete BPM lifecycle less intimidating.

1. Don’t try to boil the ocean – start with very few simple but high impact business processes

2. Clearly define business measures and key performance indicators (KPIs), and set realistic improvement targets - Setting business performance improvement targets sets the focus firmly on performance monitoring and optimization (which requires implementing complete BPM lifecycle) rather than only focus on Process modeling & white boarding exercise that very often leads into intellectual deliberations that far from business reality

3. Don’t try to solve the puzzle during process analysis, wait for the real business performance analysis – One of the key value propositions of BPM is that it makes the systems agile and very easy to change. Don’t aim to completely optimize the business processes during process analysis & modeling phase. During this phase just look for the obvious pitfalls and improvement opportunities and move forward. Since BPM systems are very ease to change let the processes evolve and mature through the real process improvement feedbacks that come from business activity monitoring & analysis. I have seen many BPM projects getting caught into the ‘analysis – paralysis syndrome’, leading to enormous delays and budget escalations which most often results in key stakeholders loosing interest and  creating beliefs that BPM is one more big hollow promise of the IT industry.

4. Choosing the right tools & technologies – It’s extremely important to conduct extensive research while choosing the BPM suite. Many of the leading and widely used BPM tools are yet not fully matured on all aspects of BPM lifecycle. In fact only few BPM products have good process monitoring capabilities. Many BPM products leverage other partners’ products to cover some of the BPM lifecycle stages, including even process execution and integration engines. Such hybrid BPM suites have serious limitations in interoperability and roundtrip even between the tools within the suite. Also many of the BPM products are built on proprietary standards severely limiting the interoperability with other reporting & analysis tools and other IT systems within the enterprise. Thus selecting right BPM suite is very critical for implementing enterprise wide BPM solution that encompasses complete BPM lifecycle

5. Establish BPM governance and process owners’ office at very early stage – Many of the large BPM initiatives involve processes that are cross departmental / business functions. Implementing process management solution for such processes requires clarity on ownership. Establishing BPM governance, especially process owners, is very critical in successfully implementing and managing cross departmental processes

6. Collective ownership of Business & IT – In most organizations the BPM projects are initiated and owned solely by IT, with very little participation from business. From my experience I have learnt that if IT owns BPM projects they are often heavily focused on ‘best architecture’ and system performance (e.g. trying to reduce function latency time from 0.8 seconds to 0.2 seconds), rather than focus on building system that enables continuous improvement in business performance. Similarly, the BPM projects that are completely owned by business often tend to focus too much on improving at very early stage the business processes and user interfaces and interaction patterns, losing sight on the real goal of putting in place the infrastructure that enables continuous feedback loop for business performance improvement. It’s imortant that BPM initiatives are jointly owned by business & IT. Establishing clearly defined BPM Governance framework ensures clarity of roles & responsibilities of all stakeholders

Posted by Dhiren Mehta at 04:07 AM | Permalink | Comments (1) | TrackBacks (0)

In many enterprise IT organizations, there are separate teams those are focused on Enterprise Architecture (EA) vs. Service Oriented Architecture (SOA). So many IT executives wonder the need of two separate entities. The usual questions are 1) does one replaces the other or are they complementary? 2) are there overlaps? 3) how to decide the boundary of responsibilities?

During a recent discussion, to answer these questions I used a parallel from my daughter’s toy room. I explained ‘EA is like a Jigsaw puzzle and SOA is like LEGO builds’.

As per Wikipedia, a jigsaw puzzle is a tiling puzzle that requires the assembly of numerous small, often oddly shaped, interlocking and tessellating pieces. Each piece has a small part of a picture on it; when complete, a jigsaw puzzle produces a complete picture. Here the complete picture is the Enterprise Architecture. Each tile defines the technologies with products and packaging of it. EA brings the oddly shaped technologies together to interlock and complete the tessellation. In essence, it is often two dimensional.

SOA brings the three dimensional picture where the organizational can build new composites (the LEGO builds) using the services (bricks). The builds are often multi-level, hierarchical and extensible. 

Finally one person from the group asked- so what is Governance in Jigsaw or LEGO? The answer came from the group “it is that writings/instructions on the outside of the box or inside the instruction manual”. Looks like my analogy worked.

But, in LEGO, the governance is just guided by LEGO tubes. As per LEGO “The interlocking principle with its tubes makes it unique, and offers unlimited building possibilities. It's just a matter of getting the imagination going – and letting a wealth of creative ideas emerge through play”.

Now I am wondering whether we can have such similar simple, but powerful governance for SOA? May be yes. Lets our imagination work.  

To play LEGO online, please visit LEGO Factory  http://factory.lego.com/getstarted/default.aspx. You can conduct ‘PoCs’ and there are many “reference implementations” too.

Posted by Binooj Purayath at 06:02 PM | Permalink | Comments (1) | TrackBacks (0)