If we are lucky, we “SOA Architects” are faced with a rather modern deployment of existing applications, based on platforms such as Java, .Net or Oracle Forms. Here, the upgrade to a Service Oriented Architecture is a natural and gradual one, programmers and architects of the existing systems are used to think in terms of components, which are close (or predecessors) to services. Thus, you can quite easily sell SOA to the stakeholders of this type of environment as a mere “upgrade” to the latest technology. For example, establishing an automated workflow by introducing BPEL on top of “servicized” EJBs will provide quick wins. On developer and architect level you have people who are thinking in terms of interfaces, have XML skills and an interest in learning the next new thing. It is this type of environment we see SOA maturing and succeeding.
Yet, where SOA gets really interesting, in broad enterprise application landscapes, things are most often different. The Mighty Host is at the center of everything. Some years ago I read an assessment that 80% of the business critical code in the world’s large enterprises and government ITs is still written in COBOL. I don’t think this number has drastically shrinked since!
To approach host / COBOL developers with some SOA slides easily makes you look like some kind of freaky alien who speaks in front of humans: They know what they are doing because they are doing it that way for many many years – and it works!
The only question remains whether you are seen as a harmless alien, someone they can just ignore because he has not enough influence to actually change something. Or whether you are a recognized as a potential threat to the way IT always has has worked here. Then fear is what you will have to deal with. Many people in this environment – developers, architects, even business people live in the culture of job controls and COBOL copy books where, if you need some data from an other system you will find an easy ad hoc way. We have to deal with it: People in this environment don’t want change and will have very good points in why everything is good as it is.
Technically, SOA and mainframes can come together, the implementation culture, language and the needed skills are worlds apart.
To address this it is important to understand the audience you talk to, the culture, the language – and you should be able to speak this language. Ideally, you show them that you can solve problems in their way too, for example by creating some job control based solution. This way gaining trust, reducing alienation and establish a real relationship between people who understand each others way of thinking.
Then you can start to think about how to sell loose coupling to people who embrace point to point connections…