![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Stretch a rubber band far enough and it can hold together many disparate items; stretch it too far and the rubber band breaks, hurting the entity that stretched it and allowing all of the potentially integrated items to scatter to the floor. We can use the development tools to make the rubber band stronger, but there are finite limits to what can be achieved with this approach. At some point, we have to limit the number of items that we expect the rubber band to integrate.
In the modern enterprise, development tools are expected to stretch along two dimensions:
- On a horizontal vector, tools facilitate communication among related but quasi-autonomous programming initiatives of varying degrees of granularity.
- On a vertical vector, within each of these horizontal initiatives, tools are used to elucidate interfaces among whatever architectural layers are required for end-to-end design of the initiative (requirements to deployment stages).
The need for the vertical vector evolved as a consequence of increasing specialization in the software development industry. Tools are now leveraged to assign properties and responsibilities to distinct work groups as an analog to the object-oriented approach commonly applied to software design, itself. However, just as in software design, this process can be stretched too far. A point of diminishing returns is reached, at which tools are required to help establish increasingly complex links among an increasing number of semi-isolated, vertically aligned human work units.
The development cycle typically begins when several layers of business and technical requirements teams create and distribute tool-generated artifacts across a horizontal trajectory. Interfaces are established among related but essentially autonomous development threads, and each thread can then be assigned to a vertical development team. Tools are effective on this horizontal vector of the software development process, just as they are effective in clearly communicating interfaces among the architectural components that comprise each horizontal, autonomous development thread.
How software development evolved to this dead end
But if tool use is stretched any further down the vertical dimension than assisting a single developer to create an end-to-end solution of an assigned component, parallels between the effectiveness of an object-oriented approach to software process design vs. an object-oriented approach to software technology design breaks down — cruelly and expensively.
In the current stage of evolution of the software development process, after a couple of generations, disparate human labor teams (web tier logic and configuration, middleware tier logic and configuration, database tier logic and configuration, messaging, networking, analytics, infrastructure design, configuration and deployment, and so on) become isolated colonies, separated at times by nearly untraversable expanses of what amounts to deep space, with wide gulfs in knowledge, culture, standards, vocabulary, priorities, and patterns. Communication and interfacing along this vertical vector, even if aided by the best of tools, is bound to fall far short of the optimum, resulting in costly iterations of failures, meetings, and rework.
But the cost is felt in emotional terms, too. Gone are the days when highly-paid programming professionals felt the satisfaction of taking even a single software component from requirements gathering through deployment, seeing that their effort resulted in solving an actual business problem.
Figure 1. Current paradigm, an evolutionary dead end
So, is software development now truly so complex that only the currently evolved model of interfacing among autonomous horizontal development threads, as well as attempting to interface among wildly diverse, vertical human work units, is the most efficacious process?
No. In fact, the opposite is true. The current branch of software development process design is an evolutionary dead end. We must now back-track it and choose a more survivable course.
Proposal for a more highly evolved, rewarding approach
To avoid the financial and human losses that are inherent in the current vertically afflicted model, we should now recognize the potential watershed that advanced software development tools have placed within our grasp. Modern requirements management, architecture, development, configuration, and testing tools, such as those offered in the various IBM® Rational® software tools, enable unprecedented advances through devolving the development process.
Tools can now be leveraged to enable what I call single Autonomous Programming Experts, or APEs, to create all of the vertical layers of any single autonomous, horizontal software component, from requirements to deployment. Endless gaps in interfacing multiple sub-components of an assigned component can now be closed by using the tools, not in an attempt to close communication gaps among vertical human groups, but, instead, to create the type of tightly integrated elements that can be achieved only in a timely and accurate manner by having the same APE create all of the elements. Endless meetings, redundant documentation, redundant human mediators, and resulting miscommunication can all be eliminated by an elite shrewdness of tool-wielding APEs.
APEs also use the tools to communicate well-defined interfaces with horizontal components created by other APEs. Tools have always been best applied to this horizontal dimension, and so optimal results are better ensured with this use of the tools than with using them along the vertical vector.
Figure 2. Highly evolved alternative process model
Of course, APEs cannot operate in a legacy, vertically oriented enterprise; they would need to function within an environment structured to support APEs. Initially, organizations would have to invest in cross-functional training and robust tool suites. But most existing code monkeys have already had to learn how to perform duties outside of their narrow, assigned discipline just to coerce various components of their code to finally work properly. In addition, most organizations have training and tools budgets, and these will be increased when the costs are seen to be far outweighed by the faster time to market and the more stable, easier to maintain, better documented applications that could be produced by APEs.
Analogous to APE software development, infrastructure requirements, architecture, configuration, deployment, and testing should also be performed by tool-wielding, human teams closely related to APEs. APE-oriented software/ infrastructure organizations would have to restructure their human resources to be, well, more human. Rather than deploying many lower-paid, factory-type workers who churn out-of-context, vertical products that are meaningless in isolation and that require an army of mediators to make those products fit with other sub-subcomponents, organizations would need to field fewer, well-trained, tool-wielding APEs, who derive great pride and job satisfaction from their efforts. Highly motivated APEs would then contribute to a company's success by creating optimized software that most efficiently meets real-world business needs.
Learn
- Visit the Rational software area on
developerWorks for technical resources and best practices for Rational
Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM
products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
- Improve your skills. Check the Rational training and
certification catalog, which includes many types of courses on a wide range
of topics. You can take some of them anywhere, any time, and many of the "Getting
Started" ones are free.
Get products and technologies
- Get the free Trial
Download or check the Trials
and Demos page for Rational software.
- Evaluate IBM software in
the way that suits you best: Download it for a trial, try it online, use it in a
cloud environment, or spend a few hours in the SOA
Sandbox learning how to implement service-oriented architecture
efficiently.
Discuss
- Join the Rational
software forums to ask questions and participate in discussions.
- Share your knowledge and help others who use
Rational software by writing a developerWorks article. You'll get worldwide exposure, RSS
syndication, a byline and a bio, and the benefit of professional editing and
production on the developerWorks Rational website. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and
YouTube, and add your
comments and requests.
- Ask and answer questions and increase your
expertise when you get involved in the Rational
forums, cafés, and wikis.
- Connect with others who share your interests by
joining the developerWorks
community and responding to the developer-driven blogs.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
