Guest View: The Horizontal Tool Integration Imperative - Software Development Times On The Web

Guest View: The Horizontal Tool Integration Imperative
By Susan Kunz

January 15, 2008 — While vertical tool integration might be good for vendors—stickiness equals revenue, equals lock-in, equals more revenue—consequences for customers aren’t all that positive. What are we solving for: vendor profitability or better software, faster and cheaper? Certainly vertical integration means at least some tools might work together, in some form or fashion, but no one has cornered the market on brain cells in today’s world, which is why a diverse portfolio of tools and applications will always be necessary.

Baby steps get you nowhere. It’s time to start thinking about how to deliver step-function improvements in quality—and this will require horizontal integration, or tools that talk to tools across vendor boundaries—i.e., time to play nice together. Expose those APIs and internal data formats. Add capabilities for data export and import.

I recently looked across our own development environment and was shocked to see what a significant contribution we are making to Intel and AMD’s top-line growth, not to mention global warming. We have a somewhat standard continuous integration environment that compiles code every five minutes if changes in our source code management system have been detected, integrates nightly, runs regression tests and a bunch of the other well-known tools.

The hitch is that most of these tools spend most of their time doing the same things: a compiler (parses source, builds an abstract syntax tree [AST]…), PMD for static analysis (parses source, builds an AST...), FindBugs for static analysis (parses byte code, builds an internal structure…), Dependency Finder for interdependency mapping (parses byte code, builds an internal structure…), Ounce Labs for source code security (parses source, produces internal representation…), SWaudit for continuous software quality audits (parses source, produces internal representation…), EMMA for line coverage (instruments bytecode…), Cobertura for branch coverage (instruments byte code…), Infrared for performance profiling (instruments byte code…)…well, you get the picture.

Streamlining the Process
So let’s think about how to streamline this. Parse source once, create “openly available and published abstract syntax tree” once, analyze many. Parse byte code, create “openly available and published internal structure” once, analyze many. Instrument for all data that can be collected at the same time via an “openly available and published” instrumentation framework, collect as much as possible in a single run, then repeat as appropriate (e.g., for performance profiling, footprint analysis, etc.).

Not only would this lower the HVAC bill, but it would also free up a cadre of really smart developers who could be working on the next big thing instead of writing or retrofitting yet another parser.

Eclipse is actually a wonderful, albeit isolated, example of how sharing can move an industry forward. Bravo, IBM/Rational and the rest of the Eclipse community! By opening the IDE and its APIs, among other things, third-party providers no longer need to roll their own source code viewers, and results of static analysis can be made available (with ambient feedback) in a manner in which they are immediately actionable. Also, developers need not learn multiple tools, which essentially do the same thing.

Other industries have done a much better job at architecting the engineering processes that ultimately deliver quality products in a timely fashion, delight customers and deliver shareholder value. In automotive engineering, the move from design into engineering (including third-party supplier data), analysis (structural, thermal, electrical and thermoplastics) and simulation (crash testing, wind tunnel, emissions and fuel consumption), on through manufacturing, is (almost) seamless from a data model sharing perspective. We couldn’t build the vehicles we do without this type of integration.

Of course, when it comes to embedded software in automotive production, manufacturers struggle with the same issues as the rest of the industry with software defects representing one-third of all warranty issues, a fraction that is on the rise.

So, if we think about architecting a development and test infrastructure from the ground up, it looks a lot different than the ones we knit together today. Today’s product-centric, instead of customer-centric, development leads to tool fragmentation in the market and increased pain for the user, undoubtedly a key driver for shelfware.

With a tabula rasa approach to architecting infrastructure, not only could we solve today’s tool fragmentation issues, but we could also realize the concept of automated tool flow—whereby the output of one tool becomes the input of the next. We could take a look at who does what, how and when they do it in the context of globally distributed development and quality assurance teams with nontrivial supplier relationships (the open source community, outsourced relationships, third-party development and verification and validation teams, as well as software certification providers).

We would actually look at an integrated development, quality assurance, project management, governance and software-sustaining schema across the software development life cycle and optimize for all parties involved in the process. This holistic view, where suppliers know the desired outputs of the ultimate customer, and design process inputs accordingly, would drive infrastructure to be built very differently—architecting not for a product, not even for integration, but for customer value with integrated tool flow as the natural by-product of such an approach. Yes, this is a business process management and optimization approach to software development. After all, isn’t software development a critical enabler to business success and hopefully also a competitive differentiator when it comes to delivering shareholder value?

Such a holistic approach would open up all kinds of possibilities too when it comes to measuring the process, whether it be understanding potential failure modes (what can and will go wrong), completing project risk assessments (to improved software project predictability and identify systemic issues), pinpointing quality issues including those caused by design debt and design marginality (that needs to be dealt with now or later), characterizing the process across individual or aggregated iterations of the software development life cycle (in the interest of continuous process optimization) and continuously assessing software readiness (including readiness for QA test, system integration and field deployment). Interfaces, APIs and data models that can be logically standardized (AST, byte code internal formats, APIs for accessing both, build conventions, etc., come to mind) should be logically standardized.

Think Horizontal Integration
Developers, QA and management would be the initial beneficiaries with code intelligence served up on a single silver platter—but only if we can make tools work together. I’m not proposing that this all happen overnight, but from a process architecture perspective, this is not rocket science either. The crux of the matter is that we need to think horizontal integration and tool flow.

If our tools remain siloed and work in isolation, their value is limited. But if we enable process integration across the software development life cycle, we can achieve significant improvements in efficiency, effectiveness and quality. And, as a bonus, by reducing redundant development, we can also accelerate innovation and actually remove the invisible handcuffs that keep us from truly realizing the ever-present ”do more with less” goal. Ultimately the big winners are customers who benefit from higher-quality and richer-functioning software, which is delivered more predictably.

Susan Kunz is president and co-founder of Solidware Technologies; before that, she worked at Sun Microsystems.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE OPINIONS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/1/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

SHARE 2008
8/10/2008 to 8/15/2008
San Jose
SHARE

ACM SIGGRAPH
8/11/2008 to 8/15/2008
Los Angeles
ACM SIGGRAPH

Intel Developer Forum
8/19/2008 to 8/21/2008
San Francisco
Intel

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA