LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

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.


Share this link: http://www.sdtimes.com/link/31648
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading