Service-Oriented Architecture (SOA) isn’t a new concept, but its emergence in organizations is demanding transformational leadership to be applied at all levels.
I’m assuming you already know about SOA, but I want to recap one important point. The nature of SOA is that it demands server-based technology functions, such as an accounting suite, to become the ‘infrastructure’ of business services, i.e. companies are integrating their library of applications in more sophisticated and diverse ways to reach their market or create internal synergies. This means that applications are accessed by a wider array of end-users in more diverse contexts.
Until recently, applications were in stove-pipes and were (and still are in many organizations) specific to organizational functions. For example, accounting software was particular to Finance, or Order Entry was specific to Sales. Application software had clear owners and demand for the software was specific to a group of users or a business process. Typically, it would be the department head who made the decisions on who used the software, how they used it and how it would change. So the provision of the application was generally centralized into the IT department, but the decision-makers were department specific.
SOA by itself brings nothing to change this paradigm. All SOA does is to bring a framework onto how the application is designed and built, or viewed from the outside world. But what SOA does do is to enable a totally different way of looking at how these applications can be used beyond the original organizational boundary. The functionality of an application is decomposed into services. Each service is discreet and self-contained. Suddenly, your Order Entry system isn’t an application – it’s a suite of technology services.
Now here is the rub. If you piece together new services that incorporate these bits and pieces from across your whole organization’s application estate, who owns the underlying software application now? And therefore who controls the decisions and its future? SOA challenges the authority and discretion of business leaders. It also threatens the incumbent end-user community as it invariably means that their application is used by other people.
- A VP of Sales may have had plans for his Order Entry system, but those plans must work within the overall strategy of the services that exploit the application
- A CFO may have chosen to migrate to another accounting package, but she maybe constrained because her choice isn’t compatible with the integration software out of the box
- An Order Entry clerk denies support to an external user who is using a web-based entry screen
These are just three abstract examples of what really goes on when SOA emerges. SOA, however, is part of a big picture, because SOA is a catalyst and tool for business transformation . SOA helps break down organizational boundaries by creating the concept of services as internal resources that can be tapped into easily and immediately. Just like people. And just like people in globally integrated virtual teams, these services are well defined in terms of their operating conditions and inputs/outputs.
But SOA doesn’t just happen. And in fact there are reasons why SOA won’t happen unless pushed. Because SOA challenges the incumbent, there will be resistance. In most cases, most of the knowledge and support lives within the incumbent. So projects that set out to lever the locus of control away from the incumbent face an uphill battle.
Without the right kind of leadership, SOA starts as a good business concept but results in poor results, and at best just deals with the ‘lowest common denominator’ of applications. What kind of leadership am I talking about? I refer to Transformational Leadership.
Anyone at any level can practice Transformational Leadership in this context, but there are a few roles that must be filled:
- The Transformation Authority – normally a single executive (often the CIO), who is responsible for driving the change from the top. These guys are sometimes brought in as interim leaders and don’t stick around once the transformation is complete. The Transformation Authority is there to persuade senior managers and department heads to relinquish a degree of control of their applications and to articulate a compelling vision of why. They’re also there to act as an arbiter and to make sure that the views of stakeholders are represented. The Transformation Auhority needs to be one hell of a guy. He or she is pragmatic, assertive, pushy, an excellent communicator and capable of using authority effectively. This person must have a cast-iron constitution as he/she will come under some heavy fire whilst other senior colleagues get over the initial hump of resistance. I’ve seen these people being briefed against, politicked against their favor, downright dismissed and all sorts of bad business behavior
- The Governance Minions – I don’t mean to belittle these folks, but I’m suggesting there needs to be a number of people who fulfill the role of Governance as an organization needs coverage of many technical areas, such as the design of interfaces and reusability. Governance is a pain in the ass , but it is constructive and necessary for SOA. Without governance, the least path of resistance will be sought and the ‘Transformation’ will be superficial
- Enterprise Architects – The Enterprise Architects maintain the big picture of the application estate, essentially there to know what applications do what and why. These guys may play a governance role but their primary role is to apply thought leadership to arrive at a coherent and cohesive architecture of IT services. They will manage the Enterprise Service Catalog – this forms the building blocks of business infrastructure. Your EAs should be in a position to drive the development and realization of the architecture by being connected to the business and the Business Analysts, so they play a vital role in helping to form and deliver the vision
- SOA friendly Business Analysts – BAs will be the troops on the ground that talk the same language as the business. If you get them onside you’ll find the transformation so much easier. Your BAs will effectively be your thought leaders that marry up the detail of business requirements with application design from and end-user point of view. It’s these guys that are able to decompose applications to business services at a level of detail that can be implemented. Your BAs will create the common-language between IT and Business as it relates to services and processes, so they must be empathic and articulate
- Business Relationship Managers – BRMs have become a popular role over the last 5 years or so, and their importance is no less through a SOA-enabled Business Transformation. BRMs are the key account managers from IT that do the touchy-feelie stuff and it’s their primary role to be a value-added conduit for information. The BRMs must be good listeners and be customer advocates, but in no way should they ‘go native’ – BRMs must be tasked with managing the relationship aspects of delivering the SOA plan
In my opinion, these roles are key to delivering your SOA transformation – I know this through experience. The most successful SOA initiatives were staffed with the right leaders, and leadership is the Number One ingredient. They may not be filled by people with these job titles, of course – that’s up to you.
Other reading you might find interesting: What type of CIO do you need for SOA? on the SOA Infrastructure Blog.
UPDATE: Check out this article on ZDNet which discusses the role of leadership in SOA initiatives
http://blogs.zdnet.com/Gardner/?p=2708
