SOA where are the skills?

Hi Everyone. We are half way in our 10 part SOA series, and I thought it apt to address our ever present challenge, skills.

A number of writers on the Net are stating that the dearth of skill in the SOA arena is one of the main contributing factors for retarding SOA adoption. Burton even suggests that the CIO should be replaced. While I agree with some of their statements, and I will discuss them shortly, I believe that the lack of skill goes much deeper than just SOA skill. I believe that with the emergence of any new IT wave there is a time lag where skills development has to catch up with the technology. Speak to any IT vendor and you will get a common answer. The biggest challenge to the marketplace adopting their software is the lack of people to implement it. SOA just adds to the complexity of the problem, as it is an approach, not a product, and requires the application of a new set of skills from both business and IT.

So how can we resolve the skill predicament we are in right now with regards SOA? Seeing that SOA requires organisational transformation, lets begin at the top, with the CIO. To successfully embrace SOA, the CIO role can be one of the most important transformation agents. The CIO though will require some key qualities, including being a visionary, being strategic and being viewed as strategic by the organisation’s leadership team, and lastly being an excellent communicator and in doing so have the ability to sell technology requirements to the business. Without this executive agent in place, SOA initiatives face a high probability of failure.

If a CIO change agent is in place, the next big challenge is to understand very early on in the adoption of SOA 1) the extent to which a SOA approach will be adopted to successfully underpin business transformation, 2) the roles that would be required, and 3) the skills gap. I have heard so often that SOA is no problem, the developers and dba’s will just get retrained! Huh? There are a plethora of roles that need to be identified, with an enterprise architect with a mandate to enforce architecture being one of the critical roles. A number of organisations do not have architects, and some are not mandated to enforce standards. Apart from the enterprise architect; roles such as integration, data and process architects, process modellers, business analysts, product technology administrators, service developers and testers, security and governance specialists need to be considered. Pooling resources and forming a SOA Center of Excellence are good strategies to discover and build skill and should form part of an official change management program. As SOA has the potential to span all tiers of an organisation, business needs to be represented and roles such as software, hardware and network specialists need to be part of the CoE. If the SOA CoE discovers that there is an incorrect skill matrix, skill sets should be developed or replaced as early on in the transformation as possible.

My last thought, for now, on skills, is the internal resource development versus external consultant debate. I have seen organisations outsource their entire architecture, which in my opinion, is IT suicide. An organisation needs to own their IT strategy; a consultant won’t do it for them. So if you do not have the time to wait for internal skill development, where could a consultant make sense? Apart from the obvious analyst, developer and architectural skill that could be injected tactically into a project, I believe that hiring a third party mentor would have a profound impact. Adopting SOA can be fraught with failure by overlooking necessary strategies like forming a SOA Center of Excellence and Governance strategy. A consultant who has experienced that journey would be of great use.

While I have concentrated primarily on “hard” skills in this entry, maybe a topic that we can explore in the future is; do organisations and employees have sufficient social skills to support a SOA approach? SOA is, by its very nature, requires social behaviour. It is forcing siloed mentalities and traditional dogma to be replaced by collaborative workplaces where alignment between lines of business and with IT is critical. So in essence evaluating cultural readines and applying organisational change management will be as important as planning for and developing hard skills. Either way you look at it, both soft and hard skill development should be planned for from the inception stages of business transformation.

SOA – Pay Now or Pay Dearly

Hi, and welcome to our fourth topic on the 10-part SOA series. My section focuses on how a lack of investment in certain areas, can hamper and potentially derail business transformation strategies that are relying on a SOA approach.

When I hear the phrase “doing SOA on the cheap” it means one thing to me, viz the fundamental building blocks to facilitate SOA transformation have not been followed or understood. There are though a number of investment-poor symptoms that I think could warn you of impending SOA troubles. I would break them into people, processes and technology.

If you look at the people issue, I think the most important aspect here is investing in time. As time costs money I often see SOA relegated to the corridors of the IT department because it is then easier to control. I believe that as a SOA approach should underpin business transformation, sufficient time has to be spent with business to understand the overall strategy, to gain alignment, to facilitate role transformation, determine project priorities and decide upon a funding strategy. In terms of funding, I have heard that the “spare bodies” in the IT department get thrown at a SOA initiative because it is “high risk”; no-one understands the concept and no-one would fund it, so SOA will start off small with a couple of trained developers or DBAs and never grow beyond an experiment. SOA needs the most highly skilled technical and business resources, including key external consultants, that money can buy. You get what you pay for in this game, and what you don’t want are unskilled consultants and staff putting your business under unnecessary risk.

If you look at process, I would put governance into this category. I hear that governance can come later in SOA maturity because it is an expensive overhead. On the flip side I have seen SOA projects grow from a concept to production extremely quickly, and without the right policies and procedures in place potentially bad development practices could quickly become the norm, and the execution of services at runtime could be unmanaged. I believe in putting down rules quickly in a process to prevent costly rework later. Debates continue at what point governance should begin to develop. I would say you should think about governance before you build your first service.

The last category that you need to look at is technology, which would include development and the SOA enabling technologies. If you look at development, developing a bunch of services is pretty easy. The more difficult thing to do is develop services for reusability. It is estimated that creating a reusable service to a base service is anywhere between 30 and 200% more expensive. The flipside is that using a reusable service in further projects reduces development cost between 20 and 80% of the cost of developing a base service. While this makes logical sense, no IT project manager will factor in increased development costs to incorporate the notion of reusability, when it might not bring them benefit to their immediate project. I think another way of tackling this issue would be to apply governance that would ensure that services are built for reusability and services form part of a managed service lifecycle and development culture.

Choosing middleware technology can be tricky. When funding is lacking, often skunk works projects are built with anything that is freely available, with little or no consideration to the suitability of the technology to the business and no understanding of the manageability of the final architecture when the middleware infrastructure begins to mature across an enterprise. Ripping middleware out of architectures is a difficult process and making a hasty middleware decision early on in SOA adoption can prove costly in the long term.

So maybe a parting thought is if applying a SOA approach on a shoestring is not a wise decision, how can you get the funding to make it happen? For any transformation initiative, business executives need to understand what is required for them to achieve their business strategy. If SOA is the right approach and will deliver the required business value to help them achieve their business strategies, and they agree to the principles, then you will have the business case and the mandate to begin to invest properly in time, process and technology.

All The President's SOA

I don't want to labour this point but it does make a nice introduction for what I want to write about this time out. I saw Paul Coby, CIO of British Airways present at a conference last year and one of his favourite phrases resonated with me, "There are no IT projects. Only business projects". He has a point. If you're doing technology for the sake of technology and not to help your customers or to improve your business then you're not doing it right. Now that's very easy for a high-flying CIO to say, how does he back it up. How, I wondered, does the thorny issue of executive sponsorship work itself out at BA?

Here's another quote for you, "There is nothing more powerful than an idea whose time has come." Victor Hugo this time. And, as I've blogged about before there is a single, simple, brilliant idea at the heart of SOA to prove that SOA's time has come, namely, building something once and re-using it is a good thing to do.

This famous quote of Victor Hugo is paraphrased in the movie 'The Contender'. As President Jackson Evans (Jeff Bridges) campaigns for his Vice Presidential nominee to be approved by the Senate he says "...there is no weapon as powerful as that of an idea whose time has come". As the nominee - Senator Laine Billings Hanson (Joan Allen) - finds out the idea is one thing,  having some executive sponsorship to back it up is another. And lets face it, there is no better executive sponsorship than that of the President of the USA.

You probably won't have that level of sponsorship for your SOA efforts, so you'll have to settle for executive rather than presidential. What do you need from that executive for your SOA to succeed? What areas do they need to think about to help and support SOA in your organisation?

I've identified six areas;

1. Business Strategy and Process: Organisations need IT implementations that support the business and its changing needs. This is all about thinking about the business project, not the IT project. This is about providing an environment that links the management and measurement of IT with the management and measurement of the business strategy. This is where your sponsor is a key sounding board and information resource. What are the KPI's of your organisation and how does your planning in IT help to achieve them?

2. Architecture: Nearly all organisations that I have worked in fund and build IT by projects in lines of business. This leaves enterprise-wide processes and integration to be considered as afterthoughts and creates a barrier to change. The A in SOA helps organisations build an IT environment based on standards, distribution, loose coupling, re-use and business process representation that is designed to respond to change and will operate and integrate at the enterprise level, the executive level.

3. Building Blocks: A lack of consistency and repeatability in IT implementation hinders most organisations in achieving their goals with respect to IT budgets and agility. The building blocks metaphor offers a common, standards-based foundation on which companies can deliver IT, providing a basis for achieving consistency and maximising the ability to repeat successes by reusing implementations and the core infrastructure.

4. Projects and Applications: As in point 2 above, IT is traditionally developed by projects within lines of business – often creating excessive spending on duplicate functionality and compromising the integrity of enterprise processes. Executive sponsorship here helps you to catalogue, categorise, and modernise functions offered by systems and applications – standardising the manner in which those functions are offered, while reducing redundancy and promoting consistency. Duplication goes down, re-use goes up.

5. Organisation and Governance: The organic growth of our organisations has yielded an IT infrastructure that is difficult to manage and costly to change. Concentrate on creating an organisational structure and mandate - executive sponsorship needed here if you're going to mandate anything by the way - to govern the delivery of IT in standard ways, thereby enabling IT to meet the needs of the business and optimise IT utility.

6. Costs & Benefits:The $64,000 question. What is this going to cost to build? How much is it going to cost to run? More importantly, what are the predicted benefits from using it? And remember, an IT benefit without a Business benefit is not a benefit at all. Key development metrics, productivity measures, reuse measures, general best practices and internal/external benchmarking. And how does all of that link back to the Business Strategy outlined in Point 1?

My Brazilian colleague Marcelo Simoes has also penned a take on this recently with his "Five-Step Action Plan for Executives". He makes several good points in his piece and I particularly like his Fifth step - The victory dance.

More Jeff Bridges to close with. You're probably not going to get The Dude to sponsor your SOA efforts. But get yourself a sponsor. One that can think big, start small and move fast.