[image: ZapThink] <http:///>
*Why Composition is Not Development*
Document ID: ZAPFLASH-20061130 | Document Type: ZapFlash
By *Ronald Schmelzer <[EMAIL PROTECTED]>*
Posted: Nov. 30, 2006
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<http://www.zapthink.com/report.html?id=ZAPFLASH-200653>.
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<http://www.zapthink.com/report.html?id=ZAPFLASH-20061012>.
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.
