At a time when SOA is experiencing some slings and arrows, it is hard to remember that not too long ago it was the greatest thing since sliced bread. It was, in fact, over hyped. If anything, SOA was positioned as a more dramatic break with the past than truly might have been the case.
But, as a gentlemen told me when I started with SearchSOA.com last fall, in software development there is a lot of hype around certain trends. The new trends are not that different form the old ones. "Even the old Nehru jacket eventually comes back in style."
The gentleman speaking was none other than Mark Lorenz, principal software engineer with Fidelity Investments. We were discussing SOA skill sets, and their similarities to other types of skill sets useful over the years for software engineers and architects.
For the successful software architect, said Lorenz, there are some pretty basic skills required, and they are not just for SOA.
''If you don't understand the design patterns - for example, the Model View Controller (MVC) - and you are not building an architecture that has separation of concerns, you are not ready to do services,'' he said. Similarly, established skills with distributed object technology may be a clue to who is going to be good with SOA.
As with athletes in some sports, in modern development it is necessary to focus on the ball while still watching how the whole play – or game – is unfolding. So the steeping in objects and things like MVCs described here does not suggest that one should favor a heavy emphasis on coding.
People are mistaken if they straightaway sit down at a keyboard and start coding away. They have to, Lorenz suggests, be able to do things like RUP and iteration planning.
Still "if you can't build small things, I don't see how you are going to an SOA," he adds.
These are not common skills. Does that surprise you?
"Few people using a UML [modeling] tool can sit down and understand how their system will work from both a logical and physical standpoint," Lorenz said. Understanding how you will build a system that meets requirements but does so in an organized way – that is a skill needed to do an SOA, and to do other successful software projects as well.
Send in the SOA antipatterns
Understanding the concepts, technology and tools of SOA is certainly important, said Lorenz. It is essential to know how granular to make a service, he said. Yet this too has roots in early approaches. Even predating the SOA push, distributed object developers and J2EE coders needed to create service layers that interface with remote functionality. Proper assignment of program – or 'services' – responsibilities is important.
Building a framework, which has long been the route for many a developer to truly cross over to the architect side, remains an example of the evolution to services. With the framework you are building software, but it is reusable software.
So, what is an anti-SOA pattern? Like others Lorenz points to the mindset that looks to put business logic and business rules into the data base as the wrong thing. Wasn't that one of the big lessons from the client-server era? But, let us admit it: teams are tempted to take that sort of short cut every day. No question that the SOA architect has to sometimes violently warn the herd on issues like this. That is, no doubt, an aspect of an emerging profession grounded in values both new and established.