Essay

Enterprise Agility—In Search of Graceful Integration Migration
by Rick Dove, 4/30/05,  

Today it is accepted as fact that the enterprise exists in an unpredictable and uncertain environment. Under these conditions, sustainable viability and leadership are both dependant on effective response to the unexpected. This generally requires agility in business processes and business process support.

The principle obstacles to business agility are the inertial drags of legacy IT infrastructure and entrenched organizational culture. Agility enabling solutions, such as a Service Oriented Architecture for IT infrastructure and collaborative self-organizing human interaction for culture, are promising concepts with arguable appeal. But both require radical disruptive changes in the underlying systems that support ongoing operations. Risk and affordability are the reasoned decision-making barriers, and behavioral resistance to change is the emotional barrier.

The lack of integrated IT applications at Utilities is well known as a source of unnecessary business cost, a road-block to best-practice upgrade, and a cause of business inefficiency and customer dissatisfaction; yet few Utilities are willing to attack the integration problem. "We don't know how to deal with it," is the commonly heard candid reason. Remove the frustration, and what is being said is that safe, affordable migration paths are elusive.

Too many intelligent solutions to the integration problem are major, throw-it-all-out, start-over-again projects. These can make a lot of sense on paper, but too often stumble badly and publicly during implementation. Though project cost overruns in the tens of millions are not uncommon, bigger costs are hidden in business disruption, completion delay, and unrealized expectations - not to mention the hits to personal reputations, and community and PUC respect. 

Such big projects are not the only ones that exhibit these risks and failings. Another common integration approach is what could be called islands of integration. Here the strategy is to replace some number of independent legacy applications with an integrated suite, typically focused in an area like finance, customer information, operations, or engineering. They promise a smaller project cost that may fit more readily with budget constraints, and less total business risk–but still face the unpredictable results of changing entrenched and familiar ways of conducting business, as well as inadequate communication and requirements definition between process owners and IT implementers.

It doesn't have to be that way. These risks and difficulties are not insurmountable–if their nature and the methods for mitigation are known, and if methods and approaches that fit the organization, personnel, and legacy environment are understood.

Integration risk, like any risk, is mitigated with relevant knowledge. Those who have dared the experienced have a wealth of tacit knowledge. Much of it has never been made explicit. Those in the midst of such a project are wrestling with these difficulties–typically seeing things go awry and wondering what will happen next, learning in the school of hard knocks. Those pushed to consider integration are often thinking "not on my watch." Some have no choice: merger and acquisition integration demands immediate attention.

How does one (or do many in an organization) gain sufficient knowledge to mitigate and manage this risk? First hand multi-project experience with thoughtful hard-knocks learning is one way–but typically not available in the Utility sector. One proven alternative method is collaborative knowledge-development–where teams of similarly-interested-people analyze the hard-knocks learnings of others–in a series of workshops guided by relevant  knowledge development frameworks.

Frameworks are important because they focus the knowledge development on relevant issues, situational impact, implementation and user acceptance behavior, and project management methodology leverage. And they look for the root-cause of both problematic and successful paths.

Collaborative teams are important because they bring diversity of experience and perspective, which yields risk-free accelerated learning that is both broad and developed at the level of insight. No idle statement–this approach was used extensively and effectively to develop concepts of agile systems that changed the thinking of those who participated¹, and spawned today's agile enterprise imperative and the resulting technology now available for support.

This kind of knowledge is not gained by reading vendor proposals, investigating promising technology, or reading trade magazine post-implementation stories. It happens in collaborative analysis with multiple minds in structured working activity–analyzing a diversity of approaches and situations.

The objective is to understand how to make integration projects predictable and affordable–within the constraints of any specific organizational situation. 

So...Why is integration a problem?

Requirements creep: The integrator will do what is planned, plans rarely understand the full set of needs in advance, the understanding of needs evolves as new processes are tested, the integrator complies, and the cycle iterates with unknown end. The result of requirements creep is cost overrun, extended schedules, expectation compromise, and too often, abandonment.

Responsibility confusion: Multiple systems are involved–typically with multiple vendors and integrators. Interfacing and data-consistency problems give rise to finger pointing rather than cooperative resolution. Money and margin are at stake.

Legacy systems: These are difficult and costly to interface. Replacing them with off-the-shelf alternatives is often not an option, as they are woven deeply into the fabric of custom business processes and entrenched operational needs.

Unintended consequences: Data incompatibilities come to light. Data integrity reconciliation that crosses operational boundaries demands costly, disruptive, and dig-in-your-heels resistance to change.

Complexity: the full needs of integrated interactions are just too complex to understand up front. Understandings evolve as systems are developed, tested and put into use.

Organizational behavior: Business continues. New business needs don't take time out during an integration project. Some of this feeds requirements creep. Some puts the original planned processes into question.

Human behavior: New procedures and processes have to be learned and mastered, familiar and favored practices must be abandoned for the common good, new transparency threatens unwanted exposure of less-than-perfect performance, new pressures and impatience arise from process interdependencies, chaos reigns during transition, and protracted chaos calls for an engineered I-told-you-so return to the past.

In short, the situation changes constantly–and these unanticipated dynamics are the principle cause of difficulty. Yet the typical approach develops project requirements, pursues implementation methodologies, and is contractually structured from a static point of view. Plans and contracts are based on an idyllic scenario–by both customer and supplier–and as the situation unfolds, these plans and contracts impede graceful dynamic response.

Graceful integration is the objective: predictable, affordable, risk-free, dynamically response able.

A non-utility major integration effort exhibited these graceful characteristics². It made use of a response able requirements development framework that anticipated situational dynamics up front, and employed a response able solution frameworks for both the integration architecture and the implementation process. Though broader in scope than what many Utilities are contemplating today, the approach is both scalable and rich with useful lessons-learned for the Utility sector. This effort included complete ERP support for the enterprise, but allowed each department to choose whatever ERP vendor it wished to support its business processes, and integrated these applications with legacy operational applications and new third party applications–and it was done on time, on budget, and on spec, setting new low cost and high speed integration benchmarks in the process.

As the above approach is beyond the scope of this discussion, the reader is referred to the referenced paper² as one proof of concept. From the abstract: "Ten underlying principles for agile systems were identified by examining over a hundred various non-software systems that exhibit agility. This paper outlines and discusses the first purposeful employment of these principles in an enterprise IT architecture design and implementation project at Silterra, a semiconductor foundry. Results suggest that employment of these principals can increase the predictability of major software projects and the responsiveness to change." Conservative in claims suitable for the paper's intended audience–but rich in detail and results.

Other successful integration cases exist. One at Xcel with broad impact was referenced in a recent UtiliPoint article³, but without the detail that would benefit others contemplating a similar project. Plenty of problematic cases exist as well–where learning opportunities are even greater.

Why might a Utility with a successful integration, such as Xcel, consider a project analysis in a collaborative workshop? Some will see benefit in transforming tacit knowledge into explicit knowledge, some will see benefit in exposing a greater internal group to the means of accomplishment and needs for ongoing activity, some will see benefit in sharing knowledge with others they interact with in the sector, and some will see benefit in the recognition of competency among customer and PUC communities.

Why might a Utility with a problematic implementation consider post-mortem analysis in collaborative workshop? Some will see benefit in turning implicit lessons-learned into explicit knowledge, some will see benefit in showing leadership by sharing lessons-learned, some will see benefit in unearthing the root of difficulties, and some will see benefit for developing future strategies.

Why might a Utility contemplating an integration project consider situational analysis in collaborative workshop? They will gain accelerated risk-free learning that avoids problems, an opportunity to see pros and cons of a variety of approaches, and collaborative attention to strategy development fit to the specific situation.

The objective is to understand how to make integration projects predictable and affordable–within the constraints of a specific organization's business situation. 

UtiliPoint International is organizing a ground-breaking multi-client project to develop this necessary knowledge. The project will engage personnel from eight to twelve Utilities in a like number of floating on-site workshops. Each workshop will address a different aspect of the integration experience. A structured framework-driven approach will ensure productive and applicable results. The frameworks will put focus on the dynamics and reality factors of changing requirements, changing business situations, and the inherent behavior of personnel, organizations, and implementation processes.

The value to participants is deep personal insight and visceral understanding of issues and effective migration paths. New knowledge will be chronicled in both individual workshop reports and a final summary document, but neither will substitute for personal learnings that come from collaborative workshop participation. It is not necessary for all participants to engage in all workshops in the series to gain this value–three to four have shown to be sufficient for others in similar-such projects of the past.

Findings will neither endorse nor recommend-against any specific vendor or integrator approach. The intention is to unearth the process variables that inhibit and promote predictable and affordable success. To this end the workshops will examine cases that have resulted in both success and disappointment, as well as the situations at pending and potential integration project opportunities.

Watch for the upcoming project announcement–or get a jump start by contacting Rick Dove at .

------------- References ---------

1. "Realsearch: A Framework for Knowledge Management and Continuing Education," IEEE Aerospace Conference, March 1998, www.parshift.com/Files/PsiDocs/RealsearchIEEE.pdf

2. "Fundamental Principles for Agile Systems Engineering," 2005 Conference on Systems Engineering Research (CSER), Stevens Institute of Technology, March 2005,  www.parshift.com/Files/PsiDocs/Rkd050324CserPaper.pdf

3. "Bigger than BIG and Taller than a Capital T: The Peace CIS Implementation at Xcel Energy," Ethan L. Cohen, UtiliPoint International, May 2, 2005,
   www.utilipoint.com/issuealert/article.asp?id=2473

========= Reply =========================
 

Home | Library
Send mail to with questions or comments about this web site.
© 1994-2005 Paradigm Shift International - Attributed Copies Permitted
Last modified: April 25, 2005