3.14. How will IT change in an ESA world? As noted earlier, and as illustrated by the SupplyOn example, IT will have its hands full in the early stages, building a fully functional backplane, populating the Enterprise Services Repository, and composing the first few generations of services before modeling tools become sophisticated and pervasive enough to disperse development beyond IT and across the enterprise. (We'll discuss that last point shortly.) But once ESA matures, what will IT's role be? Recalling the core/context model from Chapter 2, IT's twin responsibilities in an ESA world are to consolidate nondifferentiating "context" systems and to use the savings to reinvest in new, differentiating, and potentially disruptive "core" capabilities that drive process innovation. In an ESA world, debates such as the eternal build versus buy cease to matter. IT is always building core and buying context, and it is implementing both within an architecture that essentially doesn't distinguish between the two. In this environment, specialization and organization around applications or development languages are obsolete. A new IT department may look more like the vision shown in Figure 3-9 and outlined in the following list: The repository keepers oversee the care and feeding of the architecture and the Enterprise Services Repository. They define standards and guidelines, manage the service definition process, implement the backplane, keep the service repository clean and coherent, and above all, support the development of new services by the composition and innovation groups (discussed shortly). The consolidators think about context all day, every day. Once core systems have crossed the threshold from differentiating and mission-critical into nondifferentiating and best practice territory (on the way to becoming commodities), it's the consolidation group's responsibility to abstract data and services from prior investments for ultimate reuse. It's also their duty to replace systems that have outlived their ROI with commodity products or services in an eternal quest for reduced TCO. The consolidators are the ones slashing the costs that make it possible for the next two groups to receive the resources they deserve. The composers are in charge of mapping real-world business processes awaiting implementation to the underlying services produced by the environment and consolidation groups. They're the ones supporting modeling tool-equipped business analysts with their own sets of model-driven development tools. Within the context of IT, they represent a bridge between the technical skill sets of the other groups and the pure business logic of the analysts. Since the composition team's job is ultimately one of translation, its own skills revolve around its fluency in both languages. The heavy lifting is left to the disruptive innovators, IT's skunk works operating on the edge of what is currently possible, building new services and applications which cannot be modeled, but which are inherently differentiating and thus are the very essence of "core."
Figure 3-9. Transitioning the role of IT 
This reshuffling reflects what an ESA-ready IT staff might look like. Getting there will require retooling of skills and a shift in mindset away from static systems and toward the continual massaging of a landscape in flux. New development, testing, Q&A, and internal change management processes will need to be developed and refined to deploy, monitor, and administer the new service-oriented environment. The process will require a comprehensive reeducation program spanning architectures to the most granular operations. And fundamental architecture skills will be demanded of every team member as they labor to bring the ESA transformation to pass. This transformation could fail at any point if sufficient care and resources aren't set aside within IT to ensure its success. Among the areas requiring most attention are the following:
Communication Every executive and staff member from the CIO on down who is tasked with leading the charge toward ESA must communicate the urgency of the mission by whatever means necessary using whatever media is at hand. They must impress upon IT that the current architecture and ways of working will be increasingly less viable over time, and that radical change is necessary. This calls for a clear, consistent, and persistent message to the staff. They must understand that this is not "business as usual," or merely some org chart reshuffling. IT must win over those individuals who resist; they must form a general and popular consensus. And the key to all of this is steady doses of information about the why, how, when, and who of the evolution toward ESA.
Training The world of ESA will demand that IT acquire a new set of skills that have little to do with programming language proficiency. The shift toward a more model-driven architecture, for example, will demand a more conceptual approach to development that's a departure from today's hand-coded methods. Acquiring that expertise isn't as simple as hiring a dozen information architects off the street. In some cases, such as this one, the skills are in such short supply that retraining is inevitable. Before your IT department is able to execute on the ESA vision, it will be necessary to school them in it first.
Performance management The prospect of a department-wide overhaul will no doubt frighten some staffers and encourage others to resist the change passively. Impressing upon these people the importance of change and retraining staff will still fail if you don't give them proper incentives to support and embrace your efforts. This may mean rethinking your rewards systemsperhaps you should salute programmers for effectively working together with business staff to automate processes, instead of churning out clever code. Creating short-term wins that encourage your staff and prove the ROI to executives on the business side is also essential in keeping up morale and continuing institutional support.
Role modeling The last and perhaps least understood aspect of this process is role modeling. Not to be confused with other types of modeling discussed in this book, role modeling refers to quickly winning over respected individuals already within your organization and using them to champion change. Previous efforts at engineering organizationwide change, such as General Electric's vaunted "Six Sigma" methodology, included honorifics for leading practitionerse.g., Six Sigma's "Black Belts," which helped inspire other employees to follow suit. In the context of ESA, your role models may very well turn out to be your first generation of "business analysts," those individuals respected by both the business and the IT sides of the organization, and thus able to command their promise to effect change.
|
