With every new computing and architectural change comes a change in the way that companies build, manage, run, and test their applications. And with each successive wave of increasingly higher-level abstraction, the further we get from communicating with computers in the way that they understand (you know, ones and zeros) and the closer to the way in which people understand (language, patterns, and conversations). Over these past sixty-plus years of computing, the concept of IT application development hinged on the idea of encoding operations in ones and zeros, or as close to "the metal" as possible. But in the more recent history, enterprises have moved to a more abstract and conversational style of design. In moving to these increasingly more abstract representations of application functionality, at what point have we moved from something that is definitely considered "development" and something that really represents a concept different entirely from development?
Specifically, the mode of application creation and maintenance that service-oriented architecture (SOA) demands – declarative and compositional – embodies methods, approaches, and even technologies that, on the balance, are farther away from what we can consider to be development and much closer to what we can consider to be the sort of tactical and strategic planning that is necessary to the continued successful operation of a business. More importantly, SOA is shifting the balance of power from the developers of new capabilities to the composers of those capabilities to meet changing business needs. This shift requires us to understand the key differences between the composers, who are proxies for the needs of the business, and developers, who represent the technology-enablement part of the IT organization.
Composers versus developers
As companies move to adopt Service-oriented Business Applications (SOBAs), one of the first and most marked changes in development they will notice is the difference between traditional IT development and service composition. In particular, the role of the service composer is quite different from that of the IT developer. The role of a developer is to develop new application logic from scratch, rework existing application logic, or support such logic as it is deployed in specific technology environments. Developers are much like artists – no two developers produce the same application logic for the same set of requirements. In much the same way that few painters would want to paint their artwork on someone else's pre-completed canvas, most developers dislike reuse since they think they know best how to encode high-level requirements into the language that computers understand.
In addition, while most developers communicate well with computers, they don't have similar skills with people. In much the same way that developers dislike reuse, they especially dislike documentation, because they believe it gets in the way of development. IT departments often reinforce this anti-social behavior by crafting compensation and management practices that reward coding and functional development over reuse, documentation, and reduction in overall IT complexity.
Composers, on the other hand, require a different mentality and social breeding. Rather than thinking in terms new application logic development, composers think in terms of configuration of existing Services as reflecting the then-current needs of the business. Composers depend on models for their basic, day-to-day operation. Since the models that drive Service composition necessarily reflect the actual requirements of the business, composers can not even accomplish their daily goals and tasks the artifacts that developers would consider unnecessary documentation. Developers desire working code over extraneous models. Composers need working models over extraneous code.
Furthermore, the teaming environment of developers and composers are quite different. Most often, developer teams consist of a group of individual developer artists, each tasked with the responsibility of creating individual pieces of functionality mapped to a project plan that is in turn managed by a project team leader. The composition team is quite a different entity entirely. Rather than consisting of a group of individuals tied together for the sake of project expediency, a team of composers' primary responsibility is to make sure that the composition requirements of that day are fulfilled by the set of services at their disposal. If composers are in need of services that haven't been created, or must be refactored from existing services, they become the managers of requirements that would be generated for developers to encode. In this regard, while developers are solely creators of IT implementation logic, composers are both generators of composite service logic that reflects the needs of the business as well as requirements generators for the creation of new services – those services to be developed by developers, of course.
The composition process versus the development process
Another key indication that composition differs markedly from development is the way in which composition and development are done. Development is a creative process, and as such requires a logical, and somewhat fixed, process that front-ends requirements generation and testing, with results necessarily produced at conclusion. While Agile Methodologies and other approaches seek to mediate the lengthiness of the development process and move testing, in particular, to an earlier phase of creation, the effect is still the same: development is a sausage grinder with requirements coming in one end and results coming out the other. Don't ask how the sausage is made.
Composition processes are quite different. The act of composing any number of services is a relatively simple step – indeed, a service-oriented architecture demands ease of service composability by virtue of loose coupling and interoperability in the face of heterogeneity. So, given that the act of composing isn't the part that consumes most of the composer's time, the real challenge comes in managing and testing the continuously changing environment of business requirements and service implementations. In addition to necessarily being iterative, composition processes are results-driven. Rather than being a sausage grinder, composition processes are collaborative – the business knows how the sausage is made and exactly when each ingredient is added.
Composition tools versus development tools
The environment that makes developers productive is not the same as what would facilitate service composition. Integrated Developer Environments (IDEs) facilitate the creation, management, and delivery of programming logic and code, and do so either for individuals or teams of developer working together. However, these IDEs aren't intended to similarly facilitate the sort of loosely coupled, business-centric composition we require in an SOA. A number of IDEs shoe-horn service composition capabilities into their environments, but in many cases they accomplish this by supporting metadata-based Service orchestration languages like Web Services Business Process Execution Language (BPEL) as if it was simply another type of programming language. In this sort of IDE, one effectively programs compositions using XML instead of Java, C#, or any other language of choice.
What users seek is a sort of Integrated "Composition" Environment that we discussed in our SOA Killer App ZapFlash. Rather than thinking in terms of programmatic logic, composers require a variety of model-driven approaches that leverage the way that business users think over a programmatic, developer-centric style. Indeed, composers can't really use development tools at all to manage the service-oriented, composite environment. Developers can use IDEs to create atomic Services that can be consumed within a consumption-focused tool, but composers require a different tool to operate at their higher level of abstraction.
ZapThink take
In trying to split hairs between the role of the composer and the developer, one might think we're simply rehashing arguments of the past. Remember the days of the arguments that 4GL and Visual Basic developers weren't really developers at all? After all, they didn't code in assembly language or C++ or whatever the lower-level abstraction was, and so, how could they be "real" developers? In some respects, it may seem we're just arguing this case again, this time with Service composition tools and techniques being the abstract language du jour.
But the argument is really different this time. This time, the role of business logic development is not relegated to the IT department at all. The role of composite Service development as well as the budgets, responsibilities, and even user sophistication is changing. Businesses have long wished that they would be able to directly control and manipulate their technology systems without having to resort to utilizing technically skilled individuals who are proficient in the arcane languages that only computers understand. While in the past, 4GL and business-focused pseudo-code approaches have failed to successfully tip the balance of control from IT to business, we might be able to reasonably accomplish this goal if we can effectively separate the roles of the composer and developer.
Indeed, if we can continue to insist that there is indeed a difference between the role of the composer and that of the developer, we might be able to accelerate a transition towards business-sophisticated users who are technologically unsophisticated having the control they desire from the technology that is meant to enable their business needs. In many ways, this is a continuation of our discussion in the Business Modeling and Outside-In SOA ZapFlash. This direct connection between business needs and technology capability is exactly the sort of innovation we are seeking in the movement to Service-oriented Architecture.
