Key Learning from reclycling

Over the long weekend I decided to recycle all the boxes that were in my garage and following were my observations:

• I had not recycled the boxed for a very long time - so it was complete mess in the garage.
• About a decade back you could just put the boxed out and the garbage collectors would take it for recycling - not any more. We now need to break down the boxes - flatten them and stack them in the provided container in a systematic manner - otherwise they WILL leave them behind.
• As I was breaking down the boxed - realized that the technology has changed. It is very easy to flatten and stack them.
• However, there were a couple of boxes where I need to use brute force, cut them and even stand on them to forcefully flatten them. Some of them were recentely manufactured ones - guess they did not use the latest technology
• These days - eveything seems to come in box, no matter what you buy.
• It is important to recycle the boxed on a weekly basis - instead of waiting for a long time. The longer you wait the worse it gets.

Hmm!! - haven't I heard this before? :)

Yogish

Business Architecture – Process Architecture and Information Architecture!

First the problem statement - Typically the Line of Business (LoB) owned business processes and IT owned data/ information aspects. This would then help explain why these two key aspects were never in synch. The industry is now realizing the need for alignment between the process and the informational aspects and has created a new discipline of “Business Architecture” to encompass business process and business information.

Here the idea would be to leverage the business information flow in an optimal manner to drive business process definition, business process engineering and business process optimizations as opposed to shoe-horning this crucial business information into the business process. It must be noted that business information can take forms such as rules to transform business data, business decisions made in the context of an exception in the process, regulatory influences on a process or short-circuiting rules that enable a process to either be aborted without a detrimental effect on the process or rules for enabling a process to be completed quickly in “special business situations”. It is the access to this contextual business information that makes business process automation possible without losing the knowledge base of the subject matter experts.

A key goal of Business Architecture is to bring about the efficiencies of business process by access the right information. As was mentioned earlier, business architecture allows sharing of business information that is an enterprise asset in the context of a business process that is a LoB asset. Business architecture also helps highlight lost opportunities by drawing up scenarios where lack of business information availability (due to "not invented here complex" or lack of proper stewardship) prevents business process efficiencies from being realized. In addition, business process without the decision influencing contextual information still leaves the LoB user to make one off decisions that may be either based on invalid data or insufficient data and leads to process execution inconsistencies.

Furthermore, in an exceedingly inter-related enterprise or even extended enterprise sub-optimal decisions made in any business process leads contradictions in the rest of the enterprise. From an upstream process perspective, these lead to business strategies being interpreted erroneously. From a downstream perspective the business events being emitted by the siloed business process may have insufficient or improper information for execution leading to more exceptions in the downstream steps of the process. This may , slow down the entire business process chain having a negative impact on the business.

Another key goal of Business Architecture is to insure that the business information captured as part of Business Process Optimization efforts is consistent in its’ reporting. Here business process decisions made prior to the process reengineering efforts and after have to be captured consistently and accurately. This base line allows the study of the process efficiencies to be quantified. If the business information that is emitted in the form of business process based events is not being made available beyond the LoB process boundary then again sub-optimal process execution in the downstream steps could overturn the effects of any optimization work.

Information has to be captured consistently, emitted in a timely fashion and finally the events have be interpreted accurately to insure that the business strategy and the optimizations that are being envisioned by the business in implementing the value chain activities are in fact resulting in competitive advantage. This knowledge enables further process improvements and makes it easy to deal with business process adjustments especially when enterprise is faced with making a dramatic shift to deal with changing market conditions or regulatory conditions.

Finally, business process management, business process optimization and business activity monitoring need access to a well thought out MDM philosophy and strategic analytical marts that can be accessed via informational business services. These type of information access services can combine real time operational BI, real time business events and analytical sources to "close the informational loop"!!! Please see my whitepaper on this topic as well - Closing the Loop: Using SOA to Automate Human Interaction!!

As always thank you for your feedback.
surekha -

Architecture tenets of High Cohesion and Loose Coupling

Architecture tenets of High Cohesion and Loose Coupling – Both of these tenets are related to one construct i.e. that of a “Contract”.

The term contract in information technology involves the definition of high level interfaces in the form of a coarse-grained set of operations that have well known inputs, output, clear exceptions or faults. The contract hides all of the details of implementation and allows these hidden implementation details to behave as one cohesive unit - in that it provides support for "high cohesion". By extension, in separating the client or consumer or caller of the contract from the implementation details it provides support for “loose coupling”.

This concept of contract works at any of the following levels:
1. sub-system interface (for example, a persistence sub-system)
2. component interface (for example, a remote monitor)
3. layers of architecture (for example, business layer vs. presentation layer)
4. infrastructure service (for example, a messaging service)
5. SOA style business service (an customer account self-service)

Furthermore, the concept works whether the implementation is a local call or a remote component call long as the "contract" is honored. Experienced architects also insist on unidirectional contract-based communication even between the layers of the architecture - with communication only being allowed to the very next layer down. The concept is that the more volatile layers interact with the more stable layers’ contract without skipping levels. This level of indirection adds as a check for the entire system as the volatility of top level layers and the communications from the volatile layers’ are limited to the very adjacent layer alone without affecting multiple aspects of the system when these layers change.

This concept is the key driver of the Model View Controller or MVC pattern wherein the presentation layer is allowed to talk to the interface or contract of the controller layer or the façade layer alone but not to the interface in the business logic layer or the data logic layer. Also, the façade layer or the controller layer is not allowed to communicate to the client or the presentation layer. The contract dictates that it is the client or the presentation layer that is responsible for initiating the communication.

Advantages of adhering to the Contract:
A) Implementation details can change without negatively affecting the consumer or the client. Loose coupling facilitated by the contract protects the client or consumer. Also, since the behavior is highly cohesive (all hidden behind the contract in one well-knit codebase) any alterations to business rules or behavioral logic is embedded in this codebase, thus insuring the completeness of apply the rule/ logic change. Without this it is very possible that part of the logic is embedded in consumer codebase and part of it may also be placed in the communication or the mediation layer (leading to the anti-pattern low cohesion and high coupling).
B) System integration testing and performance optimizations are easier when there is a known finite set of operations, inputs and outputs that will be allowed by the contract.
C) Understanding the interactions and invocations for the consumer becomes easier due to the known and pre-configured set of operations that are published on the contract. This helps to make the system or application more deterministic.
D) As long as the contract is not broken in making behavioral enhancements new consumers can be entertained without having to create newer versions of the codebase. Of course, this can also mean addition of newer audit and tracking capabilities in compliance with internal or regulatory policies without affecting or "informing" the consumer.
E) Since the consumer is not interacting with multiple internal points of the codebase, the system interactions and resource utilizations per consumer/ client call are more quantifiable and predictable. This makes it easy to scale the system for availability. This contract or interface then becomes the single point of entry for all interactions and is thus the only point that needs to be monitored to assess system resource utilizations. In addition, provisioning of system resources becomes more scientific as all calls of a certain operation take a known amount of time and resources given that the inputs are also quantifiable.

As can be seen, a simple construct such as “Design by Contract” when taken seriously and to its logical conclusion renders a great deal of architectural stability, robustness and extensibility.

As always your comments are welcome.
surekha -

Key learning from Home Entertainment/Automation that can be applied to SOA/SaaS

Unlike the previous generation where technology innovation was driven by enterprise needs, over the past few years technology innovation such as smart phones, multimedia, game consoles, multimedia and social networking is being driven by the consumers. In short the consumers have gone digital, whether it is HDTV, Blue-ray, Home automation, smart phones, media servers or IMS (IP Multimedia Services). The vendors manufacturing these devices and services understood that unless there are standards adopted by industry - the consumers would not adopt these technologies (especially as they are not cheap). It is for this reason, most of the large vendors (hardware, software, manufacturers, protocol stack providers, etc.) got together to form the Digital Living Network Alliance (DLNA).


Their objective was to resolve the following consumer challenges:

• Products designed for the home should be easy to install, provide noticeable user value and be affordable
• Product must inter operate with each other without requiring the consumer to undergo complex setup and configuration for connection between devices
• Digital home products must inter operate with each other and with existing CE devices such as TVs and stereos.

Doesn't this sound very similar to the current IT Operations challenges?

The above diagram illustrates DLNA's view of the customers needs (source: DLNA). In order to be vendor neutral and provide the consumer the ability to control any service (yes! they call it services) the DLNA members standardized the technology stack (as shown below - source DLNA).

The key learning here is that the vendors adopted Peer-to-Peer (P2P) for device discovery, control and Media management. For now they have all adopted UPnP, especially as most existing devices at home (desktops, laptops, storage devices, game consoles, IP based TVs, Stereo systems, network hubs, etc.) support UPnP. Some of the vendors such as Microsoft support both UPnP and WS-Discovery and it the long term (once the backward compatibility issues are addressed) the industry may migrate to WS-Discovery.

For those getting ready to purchase TVs, Phones or other Digital Devices, I would recommend you verify that they are DLNA Certified.

The next obvious question is What does this have to do with SOA/SaaS? Well! why not use this same approach for deploying services? It would make life much easier for IT Operations and potentially eliminate the need for additional ESB hops in the network. Yes! I am back on this topic :). The Services-Oriented approach, it is basically a P2P architecture, i.e. a consumer invokes a producer. As most of the large software vendors have made a commitment to adopt Services Component Architecture (SCA) and developing the SCA Run time engines, it would great if they could adopt either UPnP, WS-Discovery or some other P2P technology. The following diagram illustrated the joining of new node/service(s) to the P2P network.

Benefits:
Following are the benefits of adopting this approach:

• Based on the SCA standards -unique (logical) service name for services both for defining and invocation. Do not need to know the EPR (physical location) at the time of deployment.
  
• Multi-cast availability of service whenever an instance come up - dynamic configuration does not require IT Operations or tools (even if they are automated) to change configurations.
• Service maps (for a predetermined domain/network) maintained at each node. Complete map could be maintained in the Super peer (read up on p2p architecture for more details).
• Eliminate the need for Service Registry in production. As each instance of the node and services is maintained dynamically by the Super Peer - there isn't a need to maintain and administer a Service registry.
• Eliminates the need for having a separate monitoring agent on each node, especially as each instances could updates it's own service performance details in the P2P map.
• Universal administration tool could be used to configure one or all the instances at any node and propagate the changes across the network.
• As the consuming services would know the EPR of the producing service, this eliminate the need of an ESB.
  

The Newton: Component Model (Key technologies, OSGi, Jini, SCA) is the only run time engine I know of, that supports both P2P (Jini) and SCA. The Apache Tuscany project does claim to support JXTA (P2P) binding and have not researched it as yet.

Just my thoughts and as always do feel free to drop me line with your comments and/or feedback.

- Yogish

Vendors need to focus on providing practical (real) advice

Since the end of last year - I have had the opportunity to talk to a number of CIOs, Chief Architects and business executives for large enterprises and one of the constant frustration I have heard from the end-user community (IT organizations) is the lack of practical (real) advice from the vendor community.

Following is an example of a simple Business scenarios:

• In order to increase it's revenue Business Operations would like to learn more about the customer - to identify opportunities for cross-sell/up-sell.
• They approach their partners - typically their preferred SI and/or their preferred software vendors.
• Depending on the vendor (including SI - their resell relationship with the ISV) they would recommend a Data Warehouse, Business Intelligence, EAI and/or Master Data Management Solution. In addition, they will also be willing to guarantee, typically as a fixed bid, implementation within weeks/months (typically 3 to 6 months).
• Business buys into it - spend the money and a year later had not yet achieved the end-result they were promised.

Problem:

• Vendors focus on delivering an IT solution (generate the revenue and move on to the next project) instead of solving the business problem

Recommended Approach:

• As part of every engagement - both the SI and ISVs need to insist on conducting a Business workshop (prior to starting the IT implementation).
  
• Provide real-practical advices - example: for a customer master the vendor typically looks for decision from the business to provide them with direction on where to add the customer - Lead Management, Opportunity Management or Order Management. As the vendors have done multiple implementations - shouldn't they know the best practices in the vertical and recommend the approach?
• SI typically have separate organizations that deal with business transformations and IT (CRM/ERP )implementation teams. Shouldn't every engagement have folks from both the practices at the customer site during the initial stages? Agreed the engagement cost will be a bit higher for the customer - but the value received will be substantial greater than the up-front cost. I for one - would be willing to pay. My problem was that no one approached me with such a proposal. However, I was lucky - my CIO recommended (and funded) that I have a full-time architect(s) from an SI on my team.
  

Thanks to SOA - I am starting to see changes in the SI engagement models. They seem to these days more focus on Architecture & Approach first - before bringing in their implementers. However, I am yet to see this transition happening in the ISV community.

The above example is based on my own experience and the case study is available here. As the case study indicates - I had to solve the same problem twice. First implement and learn from my mistakes and then repeat it again later. If we had real advice - we would have got it right the first time.

- Yogish

Why you need a stated "service versioning policy"?

I felt I needed to expound on the topic of service versioning after I heard concerns from a few CIO level executives about needing to "support" multiple service versions. The reason stated was that maintaining multiple service versions was expensive from both a hardware and on-going support perspective.

I completely support this opinion in that if left "unchecked" - read without the right level of governance - this could turn into a maintenence nightmare (not to mention a regulatory hazard especially if the regulatory policies are not implemented uniformly across all versions). But then this is a case for having governance and not an argument against supporting service versioning policy.


I attempt to outline some reasons for defining and publishing a "service versioning policy" to support both the business need and to create an efficient resource-utilization operating model. A carefully thought out strategy of service versioning that is rigousously "governed" allows us to do some of the following:

1. support multiple versions where in business functionality may be altered based on the operating business context or business area or industry vertical
2. support multiple versions based on the user community needs (for example, invoking a service that incorporates work-flow rules vs. needing a service that is invoked as part of an automated process level interaction)
3. support multiple versions that allow an enterprise to reduce the risk to the business when introducing new business behavior or new business process optimization changes
4. support multiple versions of a service that allow the enterprise to incorporate and interject additional authorization, entitlement and audit related rules that change based on the business context and/or business user role
5. support multiple versions that allow the system administrators to provision server resources appropriately based on the QoS/SLA needs of the service consumer and the service contract definitions.
6. support multiple versions of a service to isolate more expensive business behavior calls to specific versions so as to reduce impact to all of the other consumers (For example, a version with externalized business rules while the business is "testing" a new rule would be less performant than a version where the business rule is ratified and encoded into the business logic layer. In this example the business behavior is externalized making the service version more flexible but this makes the service less performant)

Finally, I think that service versioning can be used as a strategy to both support the business need and to optimize resource utilization that in turn make consumer interactions more efficient. Thus, the "appropriate service version" is invoked based on the "right" business context.

Your comments on this topic are invaluable.

Thanks.

surekha -

End of Application???

One of the advantage of co-blogging on the same site is that you can get two view on the same topic at the same blog :). I did review both Todd's Blog on End of Applications as well as Surekha's response on the same topic. In principle I agree that it would be great to get rid of the word or term "Application" - however in my mind this would not be practical because this word is very widely used in the Business Community.

Following is something that has worked for me in the past. Business would refer to Siebel or PeopleSoft application whenever they meant CRM or Order Management. With the help from the LOB-IT (and the decision makers from Business Operations) we were able to get business to start referring to them as Forecasting Application, Order Management application and Lead Scoring Application. It took over a year to change to get business to refer to the business process as applications - instead of getting rid of the term applications.

As a true EA - in all my presentation, budgeting cycle and various leadership team meeting with business - I referred to them as "Business Solution" with no success. Business still called them "Applications". Finally, it dawned on me - it is equivalent to the common vocabulary such as we drive on a parkway and park on a driveway- we most probably will not be able to change this to "we drive on a driveway and park on a parkway" . Similarly I do not believe we can get rid of the term "Applications" (and believe me I did try my best to get rid of it :) ).

Just my thoughts on this topic.

- Yogish

Overhauled the SOA Blueprint site

The previous SOA Blueprint site was not very well organized and nor was it easy to maintain. As I was browsing through the Yahoo! Web Hosting Console I came across the "Site Solution" tool which makes it easier to manage and publish the content. Hope you like the new layout and please do feel free to send me your feedback, comments and/or any questions related to SOA.

Following are the categories of content currently posted on the site.

• SOA Practitioners Guide
• SOA Case Studies - reference to case studies published by forums, analysts and vendors
• SOA Organization and Governance
• Enterprise Architecture Frameworks - links to the most common EA frameworks
• Enterprise Architecture Resources - Resource page with information relevant to the Enterprise Architecture teams
• SOA Reference Architecture - Reference to a list of various published SOA Reference Architectures
• SOA Maturity Models - There are multiple maturity model and this page attempts to list all the major ones along with some comments, if possible.

Please feel free to also send relevant links or documents that would be useful for adopting SOA.

Key Learnings: SOA Key Success Factors (BEA-IT 2002-2006)

Based on my conversation with my peers in the industry, there is still a lot of keen desire by IT Leadership teams to understand the key success factors for adopting SOA. Following are the list of key success factors we (IT leadership team) had identified while I was the CTO-IT at BEA Systems.

1. Build the right team
2. Organize for success
3. Build coalition with business partners
4. Maintain Flexibility

The slides of these are available here. I have created a link of all my key learning blogs at my structured blog.

Key Learnings: Overcoming IT obstacle

I used to get offended whenever anyone stated that IT was an obstacle for Business, most probably because of I have been part of IT twice in my career. After giving this some thought following are some of the approaches IT could take to overcome this perception.

Business and LOB-IT agree to adopt agile, i.e. a small joint team of IT and business to rapidly deploy applications. IT Operations object and demand that the team follow the traditional application life cycle (at least for the releases) so that they can meet the business SLAs.

• This may make sense for transactional systems that are business critical - but then again, if managed right even such applications could be deployed using the agile approach. One potential approach would be to provide a dedicated set of environment (including in production) and/or include IT operations in the agile team. This enables them to rapidly deploy new capabilities every few week.

A small business team developed or procured an applications which suddenly gains a lot of momentum within the enterprise. As IT was not involved in any of the decision making, it refuses to supporting or maintain the application stating that it may not have the skill set, resources and/or the ability to support it. This frustrates the business as they see this as IT slowing down innovation.

• IT should work with business to find a solution. Couple of options include - outsources the maintenance to a third party (including hosting servers outside the IT's data center) OR IT provides only lights-on SLA for such applications.

Business comes to LOB-IT requesting a data mart - basically extract some key information from multiple systems for reporting purposes. IT comes back with a huge proposal that includes procuring hardware, reporting tool licenses, support headcount, etc. a number that business definitely cannot afford.

• Observed this across multiple large enterprises - business extract the data from sources and sends it to a third party (small business) who have the expertise to create the custom reports as well as support the business. IT needs to figure out a ways to support such business needs - otherwise, it risks being irrelevant for rapidly developing custom reports for the business.

Business is interested in rapidly rolling out a business capability with a time frame and budget in mind. IT comes back with traditional approach of selecting and deploying packaged applications with both an unacceptable time frame and budget.

• Work with business to identify a SaaS provider and either pull all the data in periodically or identify and develop the integration between the SaaS provide and the exiting enterprise applications.

These are just some examples - additional anecdotes are welcome.

Key Learnings: IT led runaway projects

A scenario where Business has approved a large IT project with the timeline keep moving out with no end in sight.

This is a case where even though Business is really interested in deploying the next generation Information Systems/Applications but IT is unable to deliver resulting into a runaway project

Best Practices:

• Set clear objectives at the beginning of the project
• Engage System Integrator to capture business process and/or requirements
• IT Architecture team is responsible for the high-level design, estimation and architecture standards
• Program Management Office (PMO) responsible for ensuring project governance
• System Integrator engaged for developing the solution, especially for packaged applications (not a core competence of IT departments)
• Engage vendors for periodic review and recommendations

Symptoms:

Following are some of the symptoms of a potential runaway project.

• One System Integrator selected for capturing business process/requirements and other for development
• Requirements handed to the architecture team for high-level design and estimation
• Architects not involved in any of the requirements gathering meeting with the business
• Business Analyst (SI) accept requirements and commit to timelines without engaging the PMO and/or the Architects
• Development handed off to multiple vendors with each of them responsible for detailed design and development
• Architecture team not engaged with the development team for ensuring the detailed design and development complies to the original business requirements and architecture standards
• Each team uses its own development tooling, builds, testing tools and approaches
• No consisting integrating testing plan or procedures put in place
• Product vendors are not engaged during the periodic reviews
• No QA process put in place for accepting code from the various (contracted) development teams
• Cost is the only factor considered for identifying developing (contract) development teams
• Builds teams unable to recreate any of the previous builds - system or sub-system levels
• No integrated process or issues tracking procedure adopted by the PMO
• Major issues not escalated up the chain by the project manager
• No clear User Acceptance criteria defined at the beginning of the project
• No clear responsibility for integrated system testing

This results in the project being delayed with the business learning about this just before the roll out. IT loosed complete credibility with the business.

Recommended Course of Action:

Following the the best course of action to resurrect such a project.

• Reconstitute the entire team - starting from the project manager
• Ensure that there is a clear defined Project life cycle defined jointly by the PMO and the Architecture team
• Ensure that the Architecture team is not an "Ivory Tower" and engaged throughout the life cycle of the project, starting from the requirements capture to the final deployment
• Architecture team consists two sets of architects; Core Architects: Responsible for understanding all the requirements, technology and process at a detailed level and Sub-System Architects: Responsible for understanding the detailed requirements, design and work on a day-to-day basis of the development team to ensure that the system meets the business requirements
• Architecture team responsible for identifying common (reusable) components
• Based on the list of common (reusable) components, create a dedicate team to build this out (preferable by the IT department)
• Identify development teams based on on cost and skills - not just cost
• No delivery commitments made to business without PM and Architecture teams review and accept the requirements
• Make sure that the major vendors are involved in some of the PMO meetings
• Clearly define the architecture standards, QA process and knowledge transfer for accepting code from (contracted) development teams
• PMO responsible for identifying a systems integration testing team as well as ensuring that a consistent build and testing procedure is adopted
• Periodic PMO meetings to track progress, issues and open items

This fictitious scenario is based on multiple conversation with my peers in the industry.

Key Learnings: Business driven runaway projects

A scenario where cash rich LOB continues to invest and drive projects with no foreseeable return on investment.

Typically in all major corporation there is at least one major Line of Business that is cash rich, i.e. this business unit tends to exceed their revenue forecast and is looking for ways to spend money during the last two weeks of quarter/financial year.

Best Practices:

• LOB should invest on Projects that is beneficial to both their business unit as well as the Enterprise
• The "IT-Board of Directors", which includes the cash rich LOB - decides which projects get funded
• Business and IT need to jointly develop an ROI before embarking on any large projects
• LOB-IT should make technology decisions in collaboration with the CIO-Staff and the EA teams
• Engage Business Consultants or Systems Integrator to provide business and technical advice/best practices

Symptoms:

Following are some of the symptoms of a potential runaway project.

• LOB sponsors the project but not willing to wait for other LOBs which may be swamped implementing a strategic project themselves or overhauling their business process/organization
• LOB determines it knows what is best of the enterprise and starts investing in what it terms as Enterprise wide project, even though there is no buy-in from the other LOBs, CIO or the Enterprise Architecture team
• LOB is a huge proponent on the divisional LOB-IT
• LOB is very critical of the CIO and/or the IT as a whole
• LOB-IT uses technology what it understands the best, without consulting the EA team. Examples: Leverage EAI tool to move huge volumes of data instead of using an ETL tool, developing data quality tools in-house instead of using appropriate tools, etc.
• Attempts to resolve Business Processes at their end, instead of working with other LOB
• LOB-IT leadership attempting to make progress in their career paths by transferring to the LOB
• The targeted end-user community is very small

Project Approach:

• Such a project typically begins with LOB initially coming to IT stating that they would like to start a project ASAP to conduct a feasibility study for looking at one of the major business process withing an enterprise.
• As IT projects are planned at the beginning of the year - IT agrees to bring in an SI to run this project (with PMO Oversight).
• Based on the feasibility study - the SI (rightly) identifies the potential issues with the business process and recommends that this be resolved at an enterprise level - presents a phased approach - PMO, Enterprise Architecture team and CIO agree to this.
• Implementation phase begins - but other LOBs are not ready to participate and redefine the end-to-end business process.
• EA recommends to both SI and LOBs that they wait until the other LOB are ready to engage (this is where the organization dynamics begins :) ).
• In order to start generating revenue SI pushes for project to begin and fix some of sub-business process later (as-if this will really work)
• The Business project manger - in order to gain executive visibility agrees with the proposal
• The other LOB teams feel sidelined and stops participating
• To avoid having a difficult conversation with the LOB, The LOB-IT agrees with the LOB and SI, against the advise to the Enterprise Architecture team and the PMO

Recommended Course of Action:

• The best course of action for the PMO and the Enterprise Architecture team is to support the project as best as they can
• Continue to ask the LOB to define the objective and ROI for every phase
• The most noticeable aspect is the objective of the project is redefined - "To understand the issues with the business process" - instead of having a real objective or ROI
• The overall cost of the project is no longer published - instead only the SI cost is published
• The projects moves through the life cycle phase - even though it never meets the predefine and agreed upon exit criteria with the PMO

On completing a couple of phases of the project, it would be abundantly clear to the CIO (provided of course the PMO does its job) whether the project is a failure or a success. Based on this data - the CIO has enough data to push for stopping the runaway project.

In short - "Support the project the best you can and let it run its course. If it was bad idea from the start - it will eventually fail and someone" (but do not expect anyone to be held accountable :) ).

This fictitious scenario is based on multiple conversation with my peers in the industry.

Next Topic:

Key Learning's: IT driven runaway projects