BPM-EAI

In the previous blog (Part 1), I discussed some of the main reasons why modernization and transformation efforts fail. The challenge in modernization and transformation is often a combination of the four reasons summarized in the blog. This post focuses on the BPM value proposition, and how BPM is essentially the main discipline and solution to achieve sustainable modernization.

Thus for the four reasons which we covered in Part 1, you have:

1. Think Big … Start Small with BPMS: It will be very difficult to find big-bang long duration and expensive IT modernization projects that have delivered on their promises. The bottom-up IT and technically focused re-architecting simply does not work. The BPMS approach is top-down and incremental: from business objectives to operationalized BPM solutions. The overall “big thinking” transformation and modernization vision will drive the initiative. However, with BPM you can, and should, start small - with projects that could easily show business value, while minimizing risks. In any mid-sized or large enterprise, there will be many potential projects for modernization and transformations. Analyzing quantitatively the projects that will provide business value and reduce risk will help prioritize the transformation roadmap and quickly demonstrate value from “low hanging fruits.” This is essential. No one will argue with success. After the initial successes with BPM solutions modernizing legacy deployment, the roadmap and maturity towards complete modernization can proceed in incremental and iterative phases - always demonstrating value and concrete results in modernizing legacy. More importantly, as the requirements for modernization and solutions change, BPM can keep pace with the ever changing business mandates.

2. Equate Modernization to BPM: A business is defined through its policies and procedures. In building BPM applications you are actually constructing an enterprise repository (assets) of your policies and procedures. These include business rules of different categories as well as your flows. It also includes your information models (data), the user interaction (UI), and integration (services). Modernization means to directly model and automate the business and procedures in BPM solutions. The business rules, as well as process flow, become explicit and visible for the business and IT to collaborate on changing and evolving them. Modernization should be viewed holistically. On the one end of the spectrum, legacy and ERP systems can be wrapped through BPM solutions. The “wrapping” means business solutions, as well as end-user operators and customers, interact through a BPM solution, which in turn accesses legacy services as needed. In some cases, the legacy solution is retired or replaced. I have covered this in a white paper on ERP modernization and transformation. At the other end of the spectrum, you have the constant need or requirement to improve and respond to change requests. Continuous improvement and change of enterprise processes is a high priority for most businesses. So is transformation and modernization. With BPM, the business and IT can speak the same language, communicated through modeled and automated policies and procedures. The transparency and visibility of the processes provides a unique opportunity to continuously change and enhance the business solutions. So BPM becomes the foundation for modernization.

3. Automated Processes with Human Participants: Legacy systems often raise exceptions that need be handled by human experts. This creates silos between the legacy solutions and manual exception case processing. BPM aggregates these through wrapping the legacies as noted above and at the same time involving human participants who will be assigned tasks to handle exceptions with complete visibility. The automation of human activities, *especially *in the context of processes involving legacy systems, is in some sense the last frontier in information technologies. The vast majority of processes within organizations are either just documented, or ad-hoc. Modernization with BPMS automates, augments, assists and guides human operators. BPMS targets the modeling and execution of processes that can handle both the “happy path” as well as exception cases involving legacy systems. Invariably humans are involved. The human participants will be assigned tasks and controlled by the BPM solutions. Business users will have end-to-end visibility and service level governance. It is the governed, automated, guided, and collaborative execution of processes involving human roles or skills as well as back-end legacy systems that make BPM solutions extremely effective in modernizing and transforming businesses holistically.

4. BPM Centers of Excellence and Governance: As we mentioned in the previous post no initiative can succeed without oversight and governance. Since BPM is the core of the modernization initiative, the COE and governance need to reflect BPM processes, people/roles, and projects. The COE governs the BPM modernization methodology. Ideally the BPM platform should provide tools and constructs to help you directly realize the objectives, guidelines, and governance practices of the BPM methodology. In each iteration and phase of the methodology, you would like to have the corresponding function in the platform that helps and guides you in realizing the objectives of the iteration or the phase. The iterative COE methodology identifies the participants, artifacts, and phases of BPM projects. The COE governance of BPM projects identifies the policies for roles, standards, decision making, and deliverables that target BPM modernization solutions. BPM is a paradigm shift in building and deploying applications. It is a new way of developing and managing enterprise solutions. The COE provides the promotion, training, and certification of BPM development talent within the enterprise. For modernization, the BPM COE governs the best architectural modernization design patterns. Often, modernization is equated with SOA initiatives. Even here the best way to achieve SOA success is through BPM. The adoption of best practices, methodologies and guardrails to guide team constituents is also part of the BPM COE. For service interfaces to legacy system the BPM COE is also responsible for the creation and management of reusable legacy integration assets.

The value proposition of modernization and transformation is compelling. Legacy systems will become increasingly expensive to maintain as the knowledge to upkeep legacy solutions is also retired with the workforce. Furthermore, in an increasingly global and competitive climate, enterprises need to continuously improve and keep up the pace with change requests. Modernization and transformation is difficult. BPM is the best bet to incrementally modernize and ttransform iteratively, while responding to continuous change requests. But BPM is not a panacea. Even with a BPM approach, the governance and continuous monitoring of results is essential to guarantee success

Posted by Dr. Setrag Khoshafian at 5:45 AM | Permalink | Comments (0) | TrackBacks (0)

Since the beginning of this millennium, there has been an unprecedented growth in telecom sector. This can be attributed to high demand for multimedia services such as data, voice, video, and the development of new wireless standards and service types. Businesses are continuously looking at faster and more cost effective ways to deliver services to customers. Today, there are many events taking place in the telecom industry bundling assorted technologies that are not limited to phone services. Earlier days, we were using dial-up internet access, which pertains to a telephone connection in a system of many lines shared by many users. A dial-up connection is established and maintained for limited time duration through telephone networks. But now, we have ample of options in our hand. We can easily click a button and get connected to the internet. One of the best and simplest options is, getting connected through broadband service types.

The growth of broadband networks is expected to gradually outpace landline communications because advancements in these technologies have continued to enable higher broadband speeds. As the broadband revolution continues, the ever increasing competition in the broadband service market is forcing broadband service suppliers to plan their strategies for delivery of triple play services, with voice, data and video provided by a single connection. Over recent years, as the internet and intranets have evolved, increasing requirements for bandwidth intensive applications such as peer to peer file sharing and tele-working have resulted in relentlessly increasing demands for higher broadband bandwidth provisioning. In addition, it offers a much wider reach, enabling anywhere and anytime interaction.
My aim is to touch upon various broadband services and associated technologies, which is the driving factor for new developments in telecom industry.

Broadband Services:

Integrated Broadband Services (IBBS) was founded in 2001 by Michael Ingram and Robert Buckfelder, both former executives at Prestige Cable.

Broadband internet is a new concept used as an alternative of traditional dial up connections. Broadband services provide faster access to internet (high-speed Internet access. Access is always on and it has the capacity to transmit large amount of data than the dial-up access.

According to the 802.16-2004 standards, broadband means having instantaneous bandwidth greater than around 1 MHz and supporting data rates greater than about 1.5 Mbit/s.

Let's know about how broadband services get differ from dial-up service.

• Broadband service provides higher-speed of data transmission. It allows more content to be carried through the transmission "pipeline", having download speeds of 256kbps or more; whereas a dialup service connects to the Internet through a phone line with a maximum speed of 56kbps.
• Broadband is always on. It does not block phone lines and there is no need to reconnect to network after logging off and no dialup costs are acquired.
• Dialup connection uses a built-in modem to connect and do not require a special router, whereas broadband requires a special router or modem to get connected to the internet.
• Broadband provides access to the highest quality Internet services--streaming media, VoIP (Internet phone), gaming, and interactive services that may not be technically feasible with dial-up service.

We will look into the various types of broadband technologies and its characteristics in the imminent blog...

Posted by Bhuvaneeshvari Sethuramalingam at 9:45 AM | Permalink | Comments (0) | TrackBacks (0)

"Please be on hold. Your call is important to us. Our banking executives will attend to you shortly".

Drives you up the wall after you hear it for the tenth time, doesn't it?
What is supposed to be a pleasing voice of the automated recording we are made to hear has now become a prime source of irritation and exasperation for most. The possibly simplest example of an automated process is now nothing short of a trigger to venting your days' frustration!

The banking industry has seemingly taken a hit in public perception of its customer service. And what's more? A recent article in ContactCenterWorld noticed and highlighted a trend that many banking big-wigs appear to be consistently beaten by some of their 'smaller' competitors in this sensitive area of customer service. According to Kevin Mountford (Banking head at moneysupermarket.com) the core issue in this regard is likely to have stemmed from the fact that banks have more often than not chosen automation over maintaining what he terms a 'personality'. Having operated for years with a cost-containment mind set, banks have chosen to make operational efficiency their priority which could be the root cause behind customers beginning to feel less-important.

But let's study a more long term perspective of the situation. Considering the current growth in developing markets, and the 90% plus penetration that banks have achieved in most saturated/saturating markets like the United States or the United Kingdom - isn't this likely to soon become a 'your loss-my gain' scenario? Can these commoditized banking services continue to grow in organic markets with the bare minimum growth potential left?
At the depth of things and as a direct influence on customer satisfaction, the key has been circled out to be innovation. Smaller banks seem to build a growing base through personalization of services, sometimes even targeted at a select segment of the population. Automation can therefore no longer be the sole answer to growth in such a zero-sum market. The order of the day has to be a carefully concocted solution that balances the stream-lining of process in a way that caters to the growing needs and extending demands of banking consumers.

BPM has proven its worth for the role it can play in transforming customer experiences for organizations. On one hand it enables process streamlining. It optimizes processes, reduces turn-around time and shortens the waiting-period that customers have to go through. And Bingo! A quicker and efficient service leads to increased customer satisfaction. But these once sure-shot solutions of orchestrating various processes through flexible technology architectures or deftly integrating customer information have now become common ground in the banking industry. This brings into the picture BPMs other core advantage - the extent to which it can synchronize human and system integration. Add to this one of BPMs many USPs in its ability to identify and counter change; it could be the trump card for your organization!

The speed at which ideas can be implemented in BPM could hold the key in a market where every player is putting in the extra effort to evolve. Innovative ideas in today's day bear fruit only when implemented in time and well ahead of your competitors. Using BPM, banks can hold their business logic as a separate segment; reuse and modify it as and when needed to bring about any change that may be required. Enterprises can thereby also open their arms to the faster enablement of best practices, constantly monitoring existing processes against market induced changes while simultaneously keeping out any process that is redundant. The focus can then suitably be shifted from less important and time-consuming processes to the actual complex but well paying ones.

Maybe, if BPM has its way, by the next time you intend to contact your banking officer, the anomaly in your account would've warranted a personalized call/message from the bank reaching out to you before you pick up that receiver!

Possible? Has anyone experienced this?

Posted by Priyadharshini Vijayan at 7:28 AM | Permalink | Comments (0) | TrackBacks (0)

For all these years of working in Integration domain, one thing that has been conspicuous is the constant factor of change. It doesn’t matter how promising a technology is in terms of ease of implementation, support for business agility, promoting better maintenance or may be user friendliness, we will invariably see that things get changed. I remember in one client (Investment Bank) we did implement an integration solution brainstorming in the meeting rooms, burning calories, staying back late in office, with impeccable architectural standards, earning accolades from various quarters, only to find that three years down the line the entire solution was migrated to another product. This makes me wonder about the lifecycle of the solution. Few days back I wrote a paper where I tried to simulate and find out if we can ever predict the change in advance to help the managers, architects make a better decision. The following two paragraphs is my POV (A consulting term which means Point of View) excerpts from that paper.

Technology lifecycle often follows growth pattern similar to product lifecycle i.e. a S shaped curve. If specific integration technologies are considered from past (for example CORBA, RPC etc) in most cases lifecycle seems to follow the S shaped curve. If you are interested you can do a little google search when you can easily find out how CORBA was deemed to be the most promising middleware option, sometime back. These days I hear that the people who were writing CORBA specifications are now busy with WSDL specification. I hope I was able to convey my point that change is always constant in the Integration Domain

Integration has various technology options for example RPC, Com D-Com, CORBA (in the past) along with many architecture patterns like Hub and Spoke, SOA etc. Just because I mentioned all these terms together it doesn’t mean that they are all related together or used in the solution. Also these days on the horizon we have virtualization and Integration-as-a-Service. For each architectural pattern there are specific products (commercial or open source) associated and marketed by different product companies. The relationship is often many to many. Thus today, if you are little bit familiar about various tools you will know how all products ( Tibco, WebSphere, WebMethods etc) support Service Oriented Architecture (SOA). Again the same software (perhaps TIBCO) will offer integration options/ patterns like sync- async, publish- subscribe etc. That’s why I mentioned the relationship is many to many.

A firm trying to leverage on an integration style (for example let’s say focus is SOA over Web services framework) will have to buy or get an off the shelf software ( like Tibco or Websphere) which will provide frameworks, tools, features to implement the Integration solution using this Integration Style. Thus an integration style will be combination of architecture style and associated product offerings. There is a tight coupling between architecture styles a product supports. For example SAP PI didn’t allow modeling processes the way its done by a BPM product. So BPM modeling was not allowed when Integration solution was being designed in SAP PI). Later I found a separate stack (ARIS) was integrated on top of SAP PI to fill in this gap. (Not sure what happened to this initiative after Software AG bought the parent company of ARIS, i won’t be able to comment on it much and also I know Gartner/ Forrester consultants must be on it ).

Anyways this doesn’t mean that firms first decide on an architectural style or an Integration pattern and then try to look for software. In most cases the reasons are business driven and product will be sold to the firm through cumulative, continuous and untiring efforts of many stakeholders( sales person from product vendors, architects with their own affinity towards certain technology, consultants, contractors and the list will go on and on) . If a firm has been an IBM shop historically, while trying to implement Integration solutions they may consider Websphere, as their product of choice. And since implemented solutions will leverage on the architectural pattern that Websphere offers, the solution design will be restricted by that product offering. Architectural styles supported by Web sphere will normally be promoted by the architects in the firm for all practical purposes. (Of course these days every product supports every other feature. If you are in doubt, please call the sales representatives of the product you know least and soon you will realise how his product will support what you need)

Reference Mode

If we have to think of a reference mode of lifecycle behavior of Integration Style we have to study the reference mode of its constituent variables namely

• Architectural pattern (e.g. SOA),

• Product/software (e.g. Mule) offerings for Integration options (e.g. Soap, HTTP) (Remember we defined that Integration Style is the combination of Architecture Style and Product offerings).

The reference mode of each of these variables will be somewhat be similar to a Technology Product Lifecycle. Thus product lifecycle and technology lifecycle has similar reference mode of behavior except for the fact that architectural pattern often outlives a product. For example SOA is an architectural style and there are many products (Example WebSphere, BizTalk, Mule etc) in the market which provides framework for SOA. Some products are start up technology products and some are products supported by big firms. Start up products may have a small lifespan. Often some products, if supported by big firms like SAP or Microsoft, will have extended lifecycle supported by multiple releases and various product enhancements. But if we look at Architectural principles they have remained constant or have been fairly consistent over a long period of time. Hence it can be said the Product lifecycle is smaller than architecture lifecycle. I have provided a diagram below for the people who are visually inclined

The blue curve is the architectural style and the green and orange curves are hypothetical product lifecycle curve. The reference mode behavior is not drawn to scale.

Thus the Integration Style will also have a reference mode of behavior as follows:

Now that I have introduced the concept for lifecycle, It won’t be fair unless I mention the significances of this lifecyle for the IT Professionals. But I would save it for the next blog.

Posted by Maloy Halder at 7:27 PM | Permalink | Comments (2) | TrackBacks (0)

Integration in layman terms - A telecom vendor has a requirement to 'integrate' (i.e. connect) the numerous systems it may have. This helps break the usual silos or data islands in the system landscape and create meaningful business events from various low level system events; enabling businesses to join the dots and form meaningful business patterns.

Telecom Business Areas -
- Billing and Provisioning (one bill for a bundle of services, online bill details, etc.)
- Managing customer relationships (customer acquisition, improving customer service, etc.)
- Order Fulfillment (Multi channel system, Order cycle time reduction, etc.)
- Regulation & Technology (quality of service, security, etc.)
- Vendor management
- Product management (new product offerings, decreased time to market, etc.)
- Merger and Acquisitions
- Inventory management (Network management, Warranty management for handsets, etc.)

There are many integrators (read software vendors with a vast product suite covering BPM, Integration (ESB, SOA) , Real time reporting, Complex Event processing, Monitoring KPIs etc.) in the market today that are good in specific business areas. Some of these provide out-of-the box solutions to support telecom processes.

Telecom firms have been embracing BPM solutions and Integration solutions with mixed results. Today, the challenge is that telecom applications are closer to the network. Couple this with new-age telecom - triple play, IP services, 3G, 4G and what not !

Integration excellence will be a key differentiator in the years to come in this industry.

This is where I would sign off; and think more about the integration progress being made by telecom firms.

Posted by Komal Sethi at 6:43 PM | Permalink | Comments (0) | TrackBacks (0)

The reputed analyst group Gartner has released its 2010 'Hype Cycle' graph for emerging technologies, which lists Cloud Computing as having reached the peak of its hype cycle and thus poised for moving into user disillusionment (Link).

For the uninitiated, a hype cycle (a term coined by Gartner) is a graphic representation of the maturity, adoption and social application of specific technologies.

According to Gartner reps, Cloud computing has "tipped over the peak and will soon experience disillusionment among enterprise users..".

The next phase on the cycle following the peak of Hype is of course the Trough of Disillusionment where they fail to meet expectations and quickly become unfashionable. This is usually accompanied by lower interest in the press and mass media thus leading to the veritable through in the interest in the technology.

Those familiar with the Hype Cycles in the past will note that most technologies usually drop off the the emerging technologies hype cycle after a year or two.

As an analyst and practitioner of Cloud Computing, I believe that it might be a bit pre-mature to place Cloud Computing on the wrong side of the peak on the hype cycle. Let me explain why.

1. The penetration is low, but the demand is real.
   The benefits of Cloud Computing have always been and still remain very tangible benefits to the business case such as lowering TCO, providing on-tap resources and metered usage. However, the penetration of the technology ( and hence the adoption) has been low in the major emerging markets of Asia due to various factors ranging from limitations of broadband facilities to government regulations.
   According to an article in NY Times (http://www.nytimes.com/2010/10/11/technology/11cloudasia.html ) , the research firm IDC estimates that the market for cloud computing in Asia outside Japan will grow to about $1.3 billion this year and will continue expanding at a rate of about 40 percent a year until 2014. Given that the small and medium enterprises have the most to gain and face fewer adoption hurdles, once the basic hygiene factors are in place, I believe this market will explode.
   This explosion will change the game in ways that are inconceivable in the limited markets where the Cloud Computing saga has been played out till now.  The number of players, both product and platform vendors as well as service providers will change radically and will most definitely feed into the hype cycle. So I believe we have a long way to go.
2. The lack of a big failure
   While this may seem counter-intuitive, I believe that one of the major drivers for pushing any big idea or technology over the edge of the hype peak is a big failure. The denial of service by Twitter following the meltdown under peak load did exactly this for microblogging which features on the infographic well on its way down-under. The lack of permeability of Amazon's Kindle into markets beyond the US (http://www.podcastingnews.com/2009/06/16/the-failure-of-the-kindle-as-a-new-media-platform/) is another example of a technology failing to live up to the promises.
   As I type this, I can't recollect any such big fiasco for the Cloud. In the absence of that, I don't believe there will be any discounting any of the future hype-drivers in the media.  

Interestingly, one of other items on the way to the trough as mentioned in the cycle is the 4G network technology. Considering that India's cellular subscriber base is set to rise to 1.159 billion by the end of 2013, making it the world's largest mobile market, according to London-based Informa Telecoms and Media's latest forecast and majority of users here have still not been exposed to 3G telephony services, it's a bit cheeky to write-off 4G telephony already.

I believe, that once the next wave of Cloud adoption is materialized, the hype will rise to a crescendo and will last for a long long time.  

Posted by Maloy Patnaik at 2:57 PM | Permalink | Comments (0) | TrackBacks (0)

Why Do Legacy Modernization Initiatives Fail?

“Modernization,” or “Legacy Transformation/Modernization” is one of those catchy business propositions that everyone agrees with. Who does not want to modernize? The term “legacy” connotes rigid, difficult to maintain, and almost impossible to change without a long highly costly engagement. Legacy pertains to systems and applications that are either home-grown or point solutions that were acquired and extended. Legacy also deals with the increasingly aging baby boomers that are approaching retirement age. Maintaining legacy systems will become increasingly expensive as the knowledge to upkeep legacy solutions is also retired with the workforce. Costs, as well as agility for change, are the main driving forces for legacy modernization and transformation.

Yet, many modernization efforts in the private and public sectors fail. For example, a recent memorandum by Peter R. Orszag - Director with Office of Management and Budget (OMB) - indicated “Federal Information Technology (IT) projects too often cost more than they should, take longer than necessary to deploy, and deliver solutions that do not meet our business needs.” He was speaking about IT projects in general. However, modernization and legacy transformation is a substantive percentage of IT budgets these days.

This is a two part blog. In this first installment we identify some of the main reasons why legacy modernization or transformation efforts fail. In the next blog, we will show how BPM Suites - both in platform and methodology - prove the best approach for successful legacy modernization / transformation.

So why do modernization initiatives fail? The reasons are basic and go to the core of what it means to modernize. Here I would like to cover some of the more basic and core reasons why modernization efforts fail. These reasons are not orthogonal or mutually exclusive. Often failure is the result of the combined effect from two or more of these reasons.

1. Big Bang Modernization Initiatives: Often with the best intentions huge and expensive initiatives are launched with modern architecture paradigms - especially with Service Oriented Architectures (SOA). These big bang SOA projects typically deploy an Enterprise Service Bus (ESB) and attempt for instance to expose as services large numbers of legacy interfaces - with no clear business objectives. Long duration, complex, ESB can be overkill - a solution looking for a problem. A lot of effort is spent on architectural integrity - mostly paper-ware, model-ware, with little or no immediate benefits. In other words a bottom-up approach focused almost entirely on modern SOA plumbing. SOA architecture patterns have their place and are often essential. But overhauling large collections of applications with a SOA stack from the bottom up, layer-by-layer, with no top down justification or rationale is the wrong approach. A modernization initiative needs to think big but start small introducing incremental business value. Large rip-and-replace monolithic initiatives cannot keep up with the iteratively changing business drivers, federal mandates, and compliance requirements. There needs to be a clear roadmap of inexpensive incremental modernization steps: balancing business visibility and ease of implementation. (More on this in the next blog.)

2. Equating Modernization to Modern Languages, IDEs, Components, and Platforms: Large organizations often have millions of lines of legacy code. The code is written in older languages such as PL/1, COBOL or C. There are also many examples of code written in proprietary languages such as SAP’s ABAP. Some modernization initiatives have attempted to replace, or extend/expand legacy (e.g. COBOL code) with more modern language coding: with languages such as Java and C#. These languages and companion component frameworks are hip. The problem is that object-oriented or component coding is still coding! The business logic is still embedded in the code and its cryptic for the business. There are little or no business transparencies. There are definitely productivity improvements in going from structured languages to object-oriented languages, tools, components or frameworks, for IT. IT resources often love these languages and platforms. Paradigm shifts - such as modernization through BPM (and more on this in the subsequent blog) are often rejected at inception. These “modern” programming languages do have advantages and provide a lot of flexibility. The problem is that they provide value for IT - not business-centric modernization, aligning business with IT. When is the last time you saw a business stakeholder go through Java code or use Eclipse?

3. Ignoring the “Human” Participants in Modernization Initiatives: As the previous point illustrated, usually modernization has been equated with IT modernization in the overall enterprise architecture stack. An end-to-end business solution also involves human participants. Actually, often legacy systems, ERP systems, home-grown systems or even modernized versions of these elevate exceptions to humans. Managing exceptions can be the majority of the effort in an end-to-end process and these are thrown to humans with no governance, automation, or enablement. In other words, if you take the total effort involved in, say, resolving a customer or citizen request, just focusing on the operational or system areas without looking at the automation or enablement of the human participants who handle exceptions, results in partial and incomplete modernization - focusing only on the systems. How about the usual processing of tasks (vs. the exceptions)? Well, here you have the flip side of this “human” dimension: the resistance to change. Since employees are trained on familiar (“legacy”) systems, replacing them without understanding how the modern solution will make their lives easier, results in an inherent resistance to change. Also, approaching “modernization” with the same data-centric mindset that still requires business users having to be dependent on desktop procedures, knowledge management, and having to use and learn multiple siloed systems will not bring the most business value out of the initiative. This could jeopardize the success of the project. So ignoring the human participant will put the modernization initiative at great risk.

4. Ignoring Governance and Center Of Excellence for Modernization: At the end of the day no initiative can succeed without oversight and governance. This is an obvious statement - but often a core cause of failed modernization initiatives. As the previous three reasons suggest, modernization initiatives are complex. They involve many legacy systems, home-grown solutions, legacy extensions, undocumented code, and a maintenance nightmare. That is the ‘fait accompli’ side. Then you have the stakeholders: IT who wants to have modern architectures and languages; a diverse user community some of whom are dissatisfied with the current status of solutions yet others who are wary of “new” solutions and change in general; and perhaps most importantly you have the business frustrated with cost overruns, delayed projects, and systems that cannot keep up with business objectives. The larger the initiative (aforementioned Point #1), the more difficult its governance. If a modernization project takes too long, by the time the project is finished it no longer meets the needs of the business stakeholder. Modernization needs a center of excellence (COE) with specific governance involving best practices, prioritization, and project monitoring. The COE provides overall oversight, prioritization of modernization projects, and continued enablement for best practices. Modernization projects will have much less of a chance for success without an established COE that oversees the people enablement, the processes for best practices, and the prioritized modernization solutions.

These are some of the main reasons why modernization efforts fail - often with devastating results. Modernization has an important organizational dimension. In a modernization initiative business needs to be empowered to directly capture their objectives and make changes. IT and business need to speak the same language and need to come together to build as well as deploy solutions with tangible business value. That cannot happen with big bang IT projects; or just with modern languages; or lack of support for cases and human empowerment; and definitely it cannot happen without governance. It can happen with a modern, complete BPM Suite and the accompanying methodologies to incrementally transform the organization: thinking big and starting small with business and IT together for tangible high business value results. More on this in Part 2.

Posted by Dr. Setrag Khoshafian at 9:25 AM | Permalink | Comments (2) | TrackBacks (0)

Will Cloud Computing bring a major change in the way System Integrators (SI) provide services especially in implementation of  BPM, EAI and B2B Packages?

In my opinion a typical SI  is normally engaged to configure a B2B-BPM-EAI package on hardware and provide a solution that meets the business requirement of the organization. This part of the business may not have a major impact especially where the SI is involved in the package implementation as the expectation is the package and hardware utilized will eventually be cloud compliant. Hence with a minor changes to its service offering an SI is already compliant to provide package implementation service on cloud.

Lets forget the Cloud jargon for a moment and step back a little and examine what has been happening till today.  A Typical SI providing services in BPM-EAI-B2B space will typically utilize the industry acclaimed range of products to meet the clients integration needs.

The typical lifecycle of package implementation will consist of,

• Requirements : Gathering and Analyzing,
• Architecture : Logical and Physical Architecture,
• Design : Functional and Technical Design. 
• Installation : Install the package on the defined hardware,
• Configuration : Configure the package based on the design,
• Customization : Customize the package as per the design,
• Build (if needed) : To build any additional capability by custom application development (may be rare but possible),
• Test and Deploy : Test and deploy the package for the consumption

• On Premise (Dedicated) : Completely owned by client deployed in Client's premises.
• Shared : Owned by the SI and is shared with other clients of the Service provider in secure way.
• Private : Owned by the SI but is dedicated to the client and not shared with others

Now lets examine the cloud scenario,

There is no major change in the lifecycle of the package implementation.

There is a change in the infrastructure on which the implementation will be done, There will be an additional scenario of deployment on the cloud, but the important thing to note is the implementation stages doesn't change. It is still going to be the IP address of the machines provided on which the implementation will be made. It doesn't matter to the SI as to whether the IP addresses are physical machines or virtual machines. Of course the configuration of the package might change slightly to use the cloud capability of the package and ensure the security of transactions have been taken care of.

By the look of it the Majority of the changes seems to be the following organization

1. Cloud Service Provider : Majorly provides Infrastructure services. They will need new mechanisms to optimize the usage of hardware resources including commissioning and decommissioning of the software depending on the service contract and release the processing power for optimized usage. This is to ensure they can reap maximum benefits from their cloud infrastructure and so can their client.
2. Package Software Product companies : These will need to align their products to actually operate on the cloud and maintain the state during commissioning and decommissioning by the cloud provider and deployment capabilities on cloud.
3. Organisation providing the virtualization software: They will need to be able to provide new and innovative features to increase the Cloud capability. We can call these products to create a "Soft Slice" of the existing hardware.
4. Hardware Product companies: The Future will dictate the Hardware Product companies to provide inbuilt hardware optimization techniques. This can be called as "Hard slice". This is more like a inbuilt master RAID Controller in hardware.

A SI is normally engaged to configure a product on hardware and provide a solution that meets the business requirement of the organization. This part of the business may not have a major impact especially where the SI is involved in the package implementation as the expectation is the package and hardware utilized will eventually be cloud compliant.

Hence I am of the opinion that the SI who provides the package implementation services will not be majorly impacted by the Cloud Computing. Would like to hear what you all have to say though.

Having said that the SI can utilize the Cloud capability of both infrastructure and packages to introduce new service offerings which will enable them to run managed services environment for a particular industry problem and thus start a new revenue stream. Though such a concept existed before with the cloud strategy the cost of providing the service and price of the service both can be optimized and will be on demand.

This address the one major problem for SI, the dilemma of "whether to invest on an industry solution before an opportunity or after an opportunity". The SI do not prefer to make huge investment for building industry solutions before an opportunity is on table and the opportunity do not want to buy a solution from SI before they have the entire solution on table. This is deadlock that can be resolved by making small investments on solutions and deploying them on cloud and increase the capacity based on the opportunity.

Please do let me know your thoughts.

Posted by Dinesh Johri at 5:40 AM | Permalink | Comments (0) | TrackBacks (0)