SOA predicates rise of the enterprise architect
As apps development becomes more abstract
Everyone, vendor and user alike, is still trying to find out 'how to SOA' as they try to turn the hype into reality. Enterprises are trying to work out how to implement infrastructures based on services, while vendors are casting round for the way to build what users want, or indeed, just define something that users might make sense of in an environment that is switching from techno-centric to business-centric.
One thing this switch will bring with it is that the ranks of what constitutes a 'developer' will expand significantly. This point was made clear at a recent IDC conference on Service Oriented Architectures (SOAs) by Laurent Seraphin, EMEA product director of Borland, who set out a possibly contentious, but arguably true, position that the fundamentals of applications development have stayed the same since the days of the punch card.
I can imagine many in the apps-dev world, particularly those with a toolset or methodology to promote, feeling somewhat aggrieved by such a suggestion. The idea that Agile Programming or Visual Studio could be considered similar to the production of punched cards is no doubt heretical, even though the fundamentals are the same: analyse a task into its logical components, use a coding system to manipulate the instruction set of a processor, and produce a result that suits the needs of that task.
But in developer terms, SOA, Seraphin contested, is a major transformation of the traditional architecture - a higher level of abstraction. In consequence, there is set to be a higher level of abstraction in applications development. The most important addition he sees coming is the development of the enterprise architect, the guy responsible for analysing what the enterprise is trying to achieve as an entity and the orchestration of all the architectures involved - data, component, service etc - into a coherent whole.
This will not necessarily be a 'techie' in the traditional sense of apps development, and will probably be someone from the 'business' side of the fence, rather than IT. That will not be a definite requirement, of course, but it will have to be someone with a good feel for what business is about. In time, as the technology side of development changes as well, chances are the distinctions between the two camps will fade away anyway.
Indeed, he implicitly suggested that 'developers' could become significantly more prominent within a business than is currently the case. One sub-text of the move towards SOA is that someone within an enterprise must end up as the owner of the business process, and it does not matter whether that someone comes from the business or IT side of the fence. What is important is that this someone must have the authority within the enterprise over both sides of that business/IT fence. In other words, someone set at a high level within the company.
And those changes to the technology side of development? Seraphin suggested that business process analysis and object modelling approaches are likely to become as important as the waterfall approach to applications development.®