How does ESA improve the relationship between business and IT?
In the past, the relationship between business and IT has at times been tense. Business wants agility to implement new strategies quickly. Requirements are handed off to IT and not only does it seem to take a long time to implement the required functionality, but often much is lost in the translation from requirements document to executable system. ESA promises to repaint this picture by, in a way, decoupling the IT side from the business side and giving each what it has always sought. For the first time, enterprises can reap the benefits of a uniform IT architecture while also enjoying a new level of flexibility in IT that's sufficient to truly meet business needs.
A fundamental principle of ESA is the separation of business logic from application logic. Business analysts gain the ability to define, change, and adapt business processes, supported by enterprise services. IT's responsibility is equally clear: it must manage the stack from the application logic down to the physical infrastructure. IT is in charge of the underlying platform for ESA: the Enterprise Services Repository. IT must also deal with operational issues, run server farms, secure the infrastructure, ensure that the network is running properly, and much more. ESA in essence improves the relationship between business and IT by making it clear who owns what and giving business a degree of independence to do what it needs to do without having an impact on IT.
This does not mean that IT and business never negotiate again, but by empowering business with agility to work with critical business processes and to compose applications from existing enterprise services, the need for an interface becomes narrower and the questions become smaller. Instead of approaching IT with a major change to a monolithic application, business gains the ability to make strategic changes without endangering the application ecosystem; again, giving each side what it has always wanted.
Where standardization becomes importantand where it is in the best interest of business itselfis in the development of new enterprise services. Enterprise services creation should be subject to a governance process to ensure that the new service "plays well" with existing services, that dependencies are well understood, that data types are standardized, and that reuse is maximized. Still, the question of whether to create an enterprise service is far smaller than the question of whether to customize the Customer Relationship Management (CRM) system, and the ability to reach a decision will be easier as well. But this begs provocative questions: who makes that decision? Who owns the enterprise services? Who has the authority to make decisions about them?