SOA guys do not embrace developers
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By David S. Linthicum
July 1, 2008 —
I’ve heard from a few developers that many SOA guys don’t like to get input from developers. I’m not sure why that is, since architecture and development go hand in hand, but I’ve heard this lesson more than a few times and would like to address it.
What’s clear about SOA is that it emerged from the world of software development. Indeed, any developer worth his or her salt has understood the value of leveraging reusable services and perhaps has created software using that approach. This bubbled up to the layer of architecture, and traditional enterprise architects understood the value of addressing many distributed systems as services and, thus, the ability to configure processes and composites on top of those services. This leads to agility, which is—or should be—the core objective of architecture.
So, one could consider SOA a blending of traditional enterprise architecture and software development. However, for some reason developers are not getting the credit, and in many instances are not welcome in the world of SOA by those who guard the door. This is a huge mistake. As a developer who has become an architect, and now a thought leader, I can tell you that it pays to understand all aspects of architecture, from development to governance.
The core issues around this topic concern politics more than technology. Many of those charged with managing enterprise architectures don’t put much stock in those charged with actually building the systems. In essence, it would be similar to architects who design an office building but have little communication with those who actually do the construction.
In the world of architecture, developers often drive innovation more so than the architects, and the holistic understanding of the entire enterprise is pretty easy to figure out in contrast to the orderly tracking and arrangement of services to form solutions. Thus, in many instances, enterprise architects don’t really have a clue. Instead they fall back on creating presentations and governance policies that do nothing to solve the complexity and rigidity crisis systemic to most enterprise architectures.
Core to the chasm forming between developers and SOA architects is that there can really be no core benefit that’s understood if this communication problem isn’t solved. Architects would not have a clear understanding of the core issues around building and deploying services, and developers wouldn’t have a chance to understand holistically the core issues within the enterprise, not to mention the business issues. That’s not good.
In the past, when I served as CTO, I made it my mission to understand just what the developers were doing and what they were thinking. Truth be told, some of my better ideas began as conversations with C++ and Java coders, and that is where much of the innovation lies today. You just have to listen.
Architects are too caught up in the management aspect of their jobs and are not paying enough attention to how their jobs would change as a result of these new approaches and technologies. Moreover, architects are in denial about the fact that many of the core architectural concepts bubble up from the bottom and are not defined by any architectural concepts or approaches. Can you say mashups?
So, what’s an architect to do? First, include developers in the group of people who assist you in driving the architecture. That means that at times you’ll have to admit that they have a good idea and leverage it. Second, get off your high horse and stop thinking like a manager or an executive, but rather like an enterprise architect. This means doing rather than presenting and driving a systemic change to the enterprise architecture that will benefit the company long term. If you can’t do these things, go find other work; you’re not helping.
So, what’s a developer to do? First, understand the concept of architecture and how it relates to development. Many developers miss that, and some do so on purpose. Truth be told, you show me a good developer and I’ll show you a good architect. Second, drive up the chain when you have issues and concepts that need addressing. Many developers are passive and don’t like to rock the boat. Remember to be diplomatic and consider the culture of the enterprise. In this case, it’s about the people, not the technology.
There are many architects who do think holistically and innovatively and, indeed, drive change consistently. However, they are scarce. The larger issues are aimed at those who just manage by magazine (or should I say manage by blog) and follow what seems to be popular, as opposed to what is correct for their architecture. That won’t get you to an agile architecture. And, at the end of the day, you’re just making things worse.
Reach analyst David S. Linthicum at david@linthicumgroup.com.
Related Search Term(s): SOA & SaaS, software development
Share this link: http://sdtimes.com/link/32414