. Updated Daily. Editions SDA India   SDA Indonesia
JAX Asia 2008 - Conference for Enterprise Java, SOA, Spring, Web Services, Ajax, Agile and more
BUSINESS ENTERPRISE SOLUTIONS ARCHITECTURE INFORMATION SECURITY WIRELESS & MOBILITY DATA & STORAGE DEVELOPMENT HARDWARE













Online Articles

 

ALM Moves to the Front of Competitive Strategy


By Eric J. Brooks

 

ALM strategy profoundly affects an enterprise’s business relationships and even its revenue model. As the role of individual IT staff becomes transparent, motivation, not micromanagement, should drive ALM’s emerging visibility.

 

Traditionally, developing applications in line with their original business objectives has been the greatest challenge facing analysts, architects and developers. In a world increasingly run by computers, few processes have been harder to manage than the design, development, testing or deployment of software. At one time, this was believed to be mostly due to the programming process’s complexity, particularly as the scope of software and development projects expanded over the last 25 years.


However, the past few years have seen a great change in the way the application lifecycle is viewed by the development community. As a result, the GartnerGroup expects worldwide revenues from application lifecycle management (ALM) to rise from US billion in 2003 to US billion in 2008. This growing emphasis on ALM is the culmination of three coincident trends that are making ALM the focus of developer attention.


Firstly, during the last ten years, many vendors including Borland, Mercury, IBM and Microsoft created powerful tools for designing, codifying, testing or deploying applications. Indeed, tools such as Borland’s StarTeam and flexible environments like the Eclipse IDE enabled individual IT staff to finally catch up with the expanding, interlinked complexity of their applications.






Fig. 1: ALM's capacity for capturing metrics in a visually friendly format is an important cornerstone of the transparency it brings to the development process


Productive Use of Tools Requires Process Management
Secondly, while these tools allowed individual ALM functions to be performed more effectively, transitional steps between the design, development, testing and deployment phases continued to be plagued by inefficiencies. Hence, the overall process continued to be mitigated by delays, unintended end-products, miscommunications, or cost overruns.


In this respect, Terry Goldman, Rational Architect for the IBM Software Group ASEAN states that, “If you have tools but not a proper process, you cannot use the tools productively.” Gradually, it became clear that unless synergy was created between each role’s tools, software development would remain a chaotic process. Brian Spring, Mercury Software’s technical practice manager for Asia Pacific says that while, “Organisations have binders of processes, these processes aren’t digitised.” – And uniting compartmentalised development processes with visible, common metrics and real-time interactivity is the key to an integrated ALM strategy.


As individual ALM tools were already powerful, attention shifted to a traditionally overlooked problem: IT functions were always perceived as a black box whose technical parameters and issues could not be understood by the rest of the organisation. It became apparent that software development’s frequent meetings and manual collaboration exercises still left large information gaps between different ALM role players, analysts, and the wider organisation. Moreover, the inevitable misunderstandings, omitted details, or ambiguous orders only became visible up in the ALM cycle’s later stages, after funds had already been sunk into a project.


Indeed, the need for such frequent meetings itself created huge productivity losses. Colin Png, director of Microsoft Asia Pacific’s developer and platform group states that, “Less time spent on collaboration allows more actual work to be done.” Nick Jackson, Borland’s managing director for ASEAN explains that to overcome this dilemma, “We have taken ALM’s technical modules, linked, exposed, quantified and managed them in such a way that individual roles are optimised.” Hence, the emerging ALM paradigm’s central goal is for transparent, real-time monitoring and resource management to be substituted in the place of manual collaboration.


From Cost Centre to Revenue Model Driver
Thirdly, ALM’s nature and role in the enterprise was changing. The incorporation of new technical innovations in enterprise software is only one factor in the application lifecycle’s accelerating speed. In addition to the intensifying competition between your organisation’s enterprise applications and those of your competitors, factors shortening the application lifecycle include new laws governing the internet, privacy legislation, new accounting regulations, revised foreign investment and taxation rules. Formerly viewed as a cost centre, these changes are transforming ALM into a critical driver of business revenue.


Unfortunately, even as ALM became more important than ever to a company’s success, the process of developing new software development remained a wild, untamed frontier. Speaking at Borland’s unveiling of the Core SDP suite, Borland’s Jackson cites a BPM Forum study where 61 percent of surveyed companies used software development to gain competitive advantage, and 63 percent stated it was a critical role in acquiring new customers.


Thanks to seamless, integrated SCM, CRM, HR management and other online systems, the proportion of interactions that occur through automated services at the customer, employee and supplier levels are all growing. Particularly in B2B and B2C relationships, the quality of online services provided are becoming an enterprise’s competitive differentiator. In this way, the delivery of new applications directly impacts both a company’s revenue model and its reputation. Hence, both the risks and payoffs of ALM strategy are becoming larger and more volatile. With the capacity to deliver quality services and innovate new ones becoming crucial to business success, ALM is moving to the forefront of competitive strategy.


Apart from accelerating the entire ALM process, these changes are causing existing applications, business rules and underlying databases to be rewritten far more quickly and to a deeper, more thorough extent than ever before. Naturally, these increase the potential risks and payoffs of an ALM strategy, while shortening the shelf life of your existing applications.


With powerful tools still not being able to tame ALM’s unpredictable nature, the problem suddenly became obvious. According to IBM’s Goldman, what was required was, “Not a black box process but an extendable process that can encompass the entire organisation.” Hence, it became apparent that individual development tools, while addressing a particular development role or stage, were not integrated with their counterparts up or down the ALM chain.






Fig. 2: ALM integrates all development cycle players into a project management approach


In addition, a lack of common, easily understandable indicator kept each ALM role isolated from the others, as well as the larger organisation and its development objectives. There was latent demand for meaningful, mutually understood metrics that could make an application’s development status transparent to staff situated at different parts of the ALM cycle, non-IT divisional managers and larger organisational objectives.


Net Augments ALM’s Outsourcing Potential and Risk
Moreover, business and technological trends such as outsourcing and the internet were raising the opportunity cost of failing to bring sanity to the ALM process. Broadband internet’s inexpensive, ubiquitous connectivity created huge scope for outsourcing-driven cost savings. At the same time however, ALM’s notorious unpredictability creates enormous scope for self-inflicted damage.


This is because ALM’s production chain is only as strong as its weakest link – and all its chain links are made of information, not steel. This is why numerous delays, cost overruns or unintended outcomes originate during handovers of work-in-progress deliverables, particularly those that are transferred from one functional role (e.g. architects) to another (e.g. developers).


More often than not, the error or miscommunication is then re-transmitted to every new step down the chain without being corrected. By the time the snafu finally manifests itself on some dissatisfied end-users, considerable resources or reputations have already been sunk or lost.


Moreover, the constituency affected by potential ALM errors is undergoing an exponential expansion of size and scope. Formerly, ALM errors only affected individual departments within an organisation. However, with the birth of LANs, such errors began to affect the entire organisation.


The delivery of internet-based CRM and SCM systems expanded the scope of damage to customers, suppliers and raises the spectre of potentially embarrassing lawsuits. With outsourcing on the horizon, ALM errors can now be propagated to overseas outsourcing partners, where miscommunications happen more easily and are more difficult to detect or correct.


Hence, with everything from call centres to X-ray diagnostics being outsourced, how can software development be remotely managed when the process cannot even be fully controlled in-house?


In response, vendors took several steps to remedy this state of affairs. Firstly, their ensemble of existing developer tools were broken down and rewritten into closely related versions customised to the needs of different role players in the development community. For example, Borland’s StarTeam and CalibreRM were rewritten into versions customised for developers, analysts, architects and other important development process stakeholders. Borland’s Jackson opines that in this way, “You are digging deeper but only on the aspects which affect you.”






Fig. 3: Borland's ALM product roadmap consists of the Core SDP tool set which addresses ALM role players (dark blue). This will be followed by layers that will bring a project management (medium blue) and executive resource allocation (light blue) overview of the development process.


Similarly, IBM redesigned Rational’s tools into editions relevant to each role in the ALM process. In the case of IBM and Borland, this was supplemented by the acquisition of companies that either had powerful ALM tools or consulting services that played a crucial role in development or deployment. IBM’s Goldman explains that, “Our professional services play an important role in knowledge transfer in the implementation of ALM systems.” Similarly, Borland’s Jackson adds that, “Our consulting arm ensures that our technical tools are implemented in the best manner possible.”


New Releases Emphasise Enterprise-wide Monitoring
At the same time, new ALM tools have been created and will continue to be released by all three big vendors. Upcoming additions to the ALM cycle are an ongoing work-in-progress with many new releases expected in the second half of this year. Generally, new additions to Borland, IBM and Microsoft’s family of ALM products tend to enable easy viewing of enterprise-wide command and control metrics.


By enhancing transparency and bringing a project management approach to ALM, these new releases will enable the ALM process to be monitored higher up the managerial chain. New ALM tools are also being targeted at the far end of the ALM cycle, where they encounter head-on competition from specialist suppliers of testing and deployment products such as Mercury.


Cross-tool integration and enterprise-wide metrics usually function through an underlying layer application such as Borland’s Core Foundation, IBM’s Rational Team Unifying Platform or Microsoft’s Visual Studio .NET. From this common database is created a dashboard format of visually-friendly, enterprise-wide metrics. This makes the entire process transparent to stakeholders both inside and outside the IT department. According to Microsoft’s Png, metrics highlighted include, “Project management diagnostics, project team performance information and methodology support.” Collectively, this newly christened concept of ALM is bringing a project management approach to the software development process.


Interoperability Supported by all ALM Suppliers
Finally, the new generation of ALM tools all stress interoperability with the products of competitors or third-party suppliers. IBM’s Eclipse IDE has long been opened to all developers. Samantha Chan, country brand manager for the IBM Rational Software Group explains, “Is .NET better than Java? That is not for us to say.” She adds that, “There cannot be one process for all organisations.” Therefore, rather than avoiding rival ALM suppliers through a proprietary approach, “We try to play with all of our competitors.”


Widely known for its platform neutrality, Borland has a long-standing partnership with Microsoft, and has identified its intention to create new, Eclipse-based ALM tools. Microsoft has also signalled its plan to make its emerging Visual Studio based ALM suite interoperable with other competing packages. By taking an open source approach, Borland’s Jackson explains that, “We are taking an adaptive rather than a prescriptive approach.”


ALM’s promising interoperability allows developers to take a best-of-breed approach to the sourcing of each role’s particular tools, as components from a third-party vendor may be more relevant to a particular organisation’s needs than those of their main supplier.


Moreover, one side-effect of ALM is to transform the scope, nature and organisational dynamics of the development process. This will occur in three different ways. First of all, ALM releases scheduled for the second half of this year will give unprecedented viewing power and control over the entire process to higher levels of management. Through these new systems, ALM’s focus is gradually climbing up the decision ladder from change management to process management.


Transparency Enables Offshoring, Real-time Resource Re-allocation
Scheduled for release later this year, tools from IBM Rational Portfolio Manager and Borland’s code-named Project Hyperion will provide ERP or SCM style control metrics. These will encompass resource allocation, skill planning and visual monitoring of multiple projects at the CEO, CIO and non-IT vice presidential level. With these additions, Borland’s Jackson opines that henceforth, “You will be managing a community of resources and making more transparent the exact details of what is going on.”


This transparency of the relative progress of all ALM players is as effective in monitoring work being done in remote locations as it is within the head office. Hence, ALM can finally join call centres and clerical processing as another business process that can be outsourced to multiple, widely distributed locations. Moreover, the unambiguous, ERP-like metrics generated enable not only simultaneous monitoring of multiple projects but an easy transfer of coding man-hours, testing time or deployment hardware from one remote project to another.


Bringing Customers, Suppliers into the ALM Process
Furthermore, the ALM process’s increasing visibility is bound to extend to remote locales far beyond internal subsidiaries or offshore outsourcing partners. As SCM, CRM and ERP systems integrate a rising number of customers, suppliers and other associates, companies are faced with a paradox: If they do not redesign those online systems that affect these parties, revenue and market share will be lost to rival competitors. At the same time, final deployment traditionally creates numerous, unexpected side-effects that could damage their relationships with customers or key suppliers.


Since ALM’s metrics can be applied across remote organisations, customers and suppliers can now be brought into the redesign process, both as stakeholders and application innovators. Transparent, real-time diagnostics that monitor development, testing and deployment will allow for a far stronger alignment between a new application’s performance and the end-users which motivated its initial design.


As the inner dynamics of not just the IT department but each ALM participant’s contribution become visible to upper management, application development’s entire character will be transformed. Henceforth, application development, testing and deployment will not be an isolated island within the enterprise but a business division subject to the same rules, controls and revenue generating expectations as all other departments.


This has the potential to create an organisational problem among managers and IT department employees. ALM systems expose the performance of individual IT staff to the entire organisation. On one hand, Borland’s Jackson concedes that heightened transparency may meet the, “Resistance to change commonly found in organisations. Some people may not like these barriers broken down.”


Use Visibility to Motivate, not Micromanage
On the other hand, management must also take care in the way it leverages ALM’s increasing visibility. Given IT’s long history of delays, cost overruns and miscommunications, there is an intuitive temptation to leverage ALM’s emerging metrics into micromanaging the entire development process – a notorious strategy that has a dubious reputation for creating disincentives and high employee turnover.


Mercury’s Spring advises us that we must, “Monitor performance rather than the entire process.” Borland’s Jackson says that balance is achieved by, “Appealing to a sense of responsibility without stifling the creative process.” This is because unlike ERP or SCM systems which monitor the flow of inanimate, material assets, with ALM, “You are managing a community of resources.”


All this implies that ALM is destined to affect organisations in two distinct phases. The first organisations that successfully implement today’s emerging ALM’s systems will enjoy a head-and-shoulder advantage over their slower rivals, at least over the medium term. In the long run however, successful companies will resist the temptation to micromanage and instead use ALM’s implicit transparency to motivate creativity. It is only this latter group of enterprises that will come to enjoy the full benefits of today’s ascending ALM paradigm.


The Application Lifecycle Management Process, Step by Step
A Short, Slightly Critical Deconstruction of the ALM Process


While reviewing the implications of deep paradigm changes, it is good to keep basic, underlying principles in mind.


Ultimately, ALM does not guarantee success any more than a superior wrench ensures better mechanical assembly. For an ALM system to actualise its potential cost savings and productivity increases, its component’s characteristics must be commensurate with the needs of the host organisation. In some cases, components from various ALM vendors may be more suitable for different parts of the same organisation.


Moreover, ALM’s flexible nature implies both obvious organisational changes as well as more subtle ones. The need to re-delegate certain tasks or development responsibilities is the more obvious change required. With regards to the latter, the paradigm’s underlying adaptability depends on the willingness of affected employees to adopt collaborative, flexible working practices on which effective ALM depends. In a nutshell, ALM is a process which constitutes the delivery of software as a continuously repeating cycle of interrelated steps, which are characterised in the following five stages.


Defining the Application
The most important aspect of this step is creating meaningful parameters. Apart from ensuring that end-products meet expectations, well-defined application parameters give the application lifecycle a cyclical rhythm and predictability.


However, too restrictive or conditional a definition will also limit the application’s flexibility and perhaps the extent to which its life can be extended. The conditions and limitations defined here can later be used when testing end-product and ensuring that what was developed is congruent with what was initially specified.


Designing the Application
This step is a critical point in the ALM paradigm’s functionality. Much communication between business analysts and architects occurs as the application’s intended functionality is reconciled with pre-existing business systems or technical limitations. By creating transparency and mutually understandable communication windows, ALM systems can play a crucial role in coordinating the efforts of analysts, top developers and system architects.


Developing the Application
With the design materialising into its final form, coders can now develop prototypes of the application. Unlike the earlier stage’s emphasis on analysts and architects, here developers and architects must step up collaborative efforts to ensure that implementation is commensurate with blueprints drafted by the software architects. By substituting emerging ALM components that provide a common set of performance indicators, there is much scope for productivity gains at this phase of the development cycle.


Recursive cycles of information, feedback and modifications flow in both directions – an architect’s initial design is modified by developers during the implementation while coders’ interpretation of the structure is altered by feedback that ALM tools provide to the architect. Truly an ALM system choke point if there was one.


Testing the Application
Code can be tested both in static formats via employing heuristic rules and BRMS parameters, or dynamically as its execution is tracked. Code is profiled to monitor and analyse application performance, thereby ensuring that the application being implemented meets business objectives and is scalable to organisational requirements. Assuming that the application was successfully defined in step 1, that stage’s parameters can now be used to create relevant, water-tight tests.


Moreover, developers who subscribe to methodologies such as Extreme Programming may opt to perform regression tests on the entire code base before committing to proposed changes. Frequently, such alternative approaches have to be encoded into the ALM system’s methodology.


Application Deployment
In choosing the best ALM tool for deploying a fully tested and completed application, performance, reliability, security, and maintenance costs are important considerations. Ideally, the chosen tool should be able to keep the application running even while updates are made, thus ensuring 24/7 availability under almost all conditions.


Needless to say, a deployment is not the application lifecycle’s end but merely its final step before these five steps reincarnate themselves some time in the (hopefully distant) future. New organisational functions arise or improvements in technology render the current system’s functionality. Inevitably, it will again be necessary to refine the system and redesign its applications, thereby returning to the initial application definition step.


The Future
At the core of these stages lies effective change management. This function is pivotal in ensuring that all team members can communicate effectively with one another. Current ALM suites are mostly focused in this sphere. However, every vendor’s product roadmap indicates that project and portfolio management suites will soon extend the visible details of these steps to progressively higher management layers.


Borland: Leveraging Interoperability, Experience and Momentum


Always the favourite of developers, Borland made it clear early on that it saw future in providing application lifecycle solutions. In Borland’s new vision, enterprises reap productivity gains by leveraging separate tools into a more efficient ALM process.


After unveiling its Software Delivery Optimisation (SDO) platform late last year, Borland recently followed up with the launch of its long-awaited Project Themis, which was unveiled as Borland Core SDP (Software Delivery Platform). Nick Jackson, Borland’s managing director for ASEAN adds that, “SDP is the first realisation of Borland’s SDO vision.”






Fig. 4: The Core::SDP components of Borland's ALM suite


Intended to act as the ALM arm of its SDO vision, Core SDP’s vendor-agnostic, role-based platform links together the work spheres of architects, developers and testers. Respectively called Core::Analyst, Core::Developer, Core::Architect and Core::Tester, every SDP tool optimises its respective role’s key functions. At the same time, a commonly shared pool of metrics enables all ALM stakeholders to monitor all aspects of the development process.


Uniting the SDP family’s ALM tools, a dashboard view of a project’s progress augmented by a rich variety of metrics provides a common status window for all stakeholders. In this way, a project management based methodology is used to drive the ALM lifecycle. Below are some components which supervise the process and create the dashboard’s metrics.


Core::Analyst delineates application requirements and interprets the effects of changes and scheduling on the overall project’s progress. Further down the ALM assembly line, Core::Architect supports code analysis, UML modelling, and design patterns while generating relevant metrics that record and audit the entire process.


Using either JBuilder 2005 or Eclipse IDEs, Core::Developer supports J2EE and web services to oversee a proposed application’s transformation into code. Integrated metrics generated by Developer include static code analysis, the processing of change requests and application test cases.


At the far end of the ALM process, Core::Tester tests newly developed or updated applications, compares their functionality to pre-defined criteria and records the system resources being used. Tester’s defect-management tools help to iron out inevitable bugs. Although these three role-based tools are all Java-based, a .NET version of each is to soon be released.


Collectively, the SDP family of products integrates into Borland’s larger SDO vision which consists of previously-released server-based tools such as StarTeam, CalibreRM, OptimizeIT, the JBuilder IDE and Together.


On Borland’s product roadmap are Project Hyperion and Project Prometheus. Hyperion is due to be released in late 2005 and features a layer of project and process management tools. Similarly, Prometheus, scheduled for release next year, will provide a new level of project portfolio management, resource and skill planning targeted at executive management and CIOs.


All these tools as well as future SDP releases operate over a common bedrock of services called Core::Foundation. Aside from stitching together separate ALM components, Foundation updates and maintains a central team depository of information, manages configuration, versioning and requirements. Hence, collaborative, reporting, project management and metrics monitoring of each SDP tool is largely derived from Foundation’s underlying database and functionality.


With respect to this release’s place within Borland’s larger Software Delivery Optimisation concept, SDP is an initial roll-out that addresses the respective ALM needs in the development community: coders, analysts and architects. Upcoming releases slated for later this year will offer SDP components that handle software development issues from project management, portfolio management, resource allocation and skill planning perspective.


Several months prior to its release of Core SDP, Borland acquired TeraQuest, a Texas-based software consultancy that focuses on the implementation of ALM and CMM systems. Besides adding value to Borland’s ALM tools, the consultancy may have been purchased with the strategic intent of competing against Rational, whose rival ALM system is complimented by IBM’s large consultancy arm.


Recognised for its platform neutrality, Borland continues to stress interoperability of its ALM line of products and is equally at ease in the Java, UML and .NET worlds. Moreover, at about the same time it released its SDP family of ALM tools, Borland announced its intention to expand the Eclipse platform’s functionality into functions such as modelling.


While this naturally strengthens the position of any ALM suites based on Eclipse, it further leverages Borland’s platform neutrality and ensures that its SDP products remain relevant regardless of whether the market swings in either Microsoft or IBM’s direction.


IBM: Eclipse to Overshadow ALM Competitors?


Hot on the heels of Borland’s SDP in the contest for ALM market share is IBM’s Rational Unified Process. Named after Rational, an ALM specialist company and former Microsoft partner Big Blue acquired in 2003, IBM is distinguished by its use and promotion of the open source Eclipse platform to integrate its components’ functionality.






Fig. 5: IBM Rational ALM's implicit underlying unity


Samantha Chan, country brand manager for the IBM Rational Software Group provides a two-fold reason for Rational’s reliance on Eclipse. Firstly, “We want a consistent interface across all platforms.” Terry Goodman, Rational Architect for the ASEAN IBM Software Group adds that, “We want to raise Rational to a level where the tools will be responsible for the implementation.”


Originally an internal IDE, IBM released Eclipse into the public domain, probably as a counterweight to the dominance of Microsoft’s .NET platform and results have exceeded expectations. The collective effect of Eclipse’s huge user base and Borland SDP’s increasing participation in Eclipse may have the effect of putting .NET-based ALM tools on the defensive.


Like Borland, Big Blue is also busy redesigning and repositioning its extensive family of pre-existing development tools into coherent, role-specific ALM suite components. For example, different parts of Rational Rose XDE for Java were formerly used by architects and developers for their various purposes, with the latter also using WebSphere. These formerly complex tools have been restructured into Rational Application Developer and Rational Web Developer. In the process of doing so, the role-specific functionality of each component makes them easier to use while transparency and collaboration are augmented.


Despite the name ‘Rational Unified Process’, Chan makes it clear that IBM’s ALM philosophy is comfortable with developers using a best-of-breed approach for each ALM tool. “Eclipse’s open API gives room for third-party suppliers.” She adds that, ”We don’t look to differentiate ourselves, we try to play with all competitors.”


The open source nature of Eclipse means that, “Everyone has a common environment and we allow third-party vendors.” “We do not expect customers to take the whole process, but to take what makes sense to them and help them implement it,” said Chan.


IBM’s Rational Unified Process encompasses all aspects of the software development lifecycle. Key features include an iterative approach to development, deployment and testing, which emphasises software quality throughout the development lifecycle.


Leveraging the open source but IBM developed Eclipse 3.0 platform, Rational’s Atlantic release emphasises tools for application testing, modelling and interacting with remote clients via its updated ClearCase Client. Eclipse’s Hyades testing and monitoring environment is also incorporated into this release. To further extend the Rational’s interoperability and scope for integration, the Workplace API Toolkit will commence shipping in the third quarter of this year.


Technologies supported include Service Data Objects (SDOs) that allow applications to interact with databases, UML modelling and interactive website construction through JavaServer Faces.


Complimenting these tools is the scheduled, third quarter of 2005 releases of WebSphere Studio Device Developer version 5.7, Workplace Builder, the WebSphere API Toolkit and Workplace Designer (in beta release).


Workplace Designer intends to bring in business users with limited programming experience in the ALM process. Its built-in scripting tools can be harnessed to construct either components in tandem with Workplace Builder or standalone applications. Studio Device Developer is designed to facilitate the adaptation and extension of traditional enterprise functions onto mobile phones and other emerging wireless mediums.


During IBM Rational Software Development Conference 2005 in May, Big Blue will provide a preview of its next ALM release, code-named Baltic. Whereas Atlantic provides development tools, Baltic is expected to emphasise an integrated, interoperable testing environment.


More than any other vendor of ALM suites, IBM brings to the table the strongest, most established global network of consultants and consultancy services. This puts Big Blue very much in the running against Borland’s comparably strong ALM offerings, and these two competitors are very much neck-in-neck.


Microsoft: The Empire Strikes Back?


Among the three ALM vendors, Microsoft is again taking its traditional role of latecomer and feared dark horse. Although a late beta of its Visual Studio platform is available for downloading, Redmond has not yet released an integrated suite of ALM products. It is scheduled to release its first generation of interoperable ALM tools late this year, about twelve months after Borland and IBM.






Fig. 6: An example of Visual Studio 2005's easy to understand graphical approach


Colin Png, director of Microsoft Asia Pacific’s developer and platform group explains that, “When we release a product, we want it to have better integration and performance. If that takes longer, we are willing to take longer.” For those who want an early taste of Microsoft’s ALM offerings, they can download the beta 2 of Visual Studio and a Go-Live license from the Microsoft website.


Moreover, do not let Microsoft’s lateness fool you – the .NET platform, Internet Explorer and Windows 9x/NT were all released long after its competitors and these dark horses arrived to dominate their respective markets. In ALM, Microsoft’s unstoppable ability to steamroller competitors through proprietary software meets the immovable reality of ALM’s open source standards.


Indeed, this issue is a source of contention between Microsoft and its competitors. For example, Microsoft is a part of the UML working group and incorporates UML functionality into its ALM suite. However, it also uses Domain Specific Language (DSL) which includes, but is not limited to, UML itself. From competitor’s perspective, this appears to be a divide and conquer strategy of subtly brining in proprietary features.


However, Microsoft’s Png believes that DSL allows ALM to extend the functional scope of an ALM system. He takes a similar controversy from the recent past in that, “When Microsoft ODBC, people thought it was ‘a Microsoft thing’ but since then, it has become an industry standard.” At this point however, it is too early to say how the unique mix of interoperability and extensions found in Microsoft’s ALM offering will play out in the market.
Acknowledging that ALM is different from previous challenges, Png states that the upcoming Visual Studio 2005 based ALM solution will be platform agnostic. Of course, just as IBM leverages the open Eclipse platform which it previously developed, Microsoft stresses the interoperability of its ALM products while using the strengths of its .NET platform. Towards this end, Microsoft’s Png stresses that Microsoft’s ALM solution was developed from, “The ground up”, and without acquiring other companies.


Like Borland’s SDP and IBM Rational, tools incorporated into Visual Studio 2005 Team are designed to support all software development roles and processes. A dashboard encompassing both quantitative and visual metrics unites all ALM stakeholders under a collaborative umbrella.


At the beginning of the ALM chain, the Team Architect Edition of Visual Studio provides tools for visually assembling service-oriented solutions. Next, Visual Studio 2005 Team Developer Edition provides static code analysis, coverage, profiling and unit testing tools that integrate with earlier and later ALM system components.


In its Team Foundation Edition, Visual Studio uses Microsoft Excel, Project, and SharePoint to offer a set of services-based project management functions. As it did in past battles with rivals, Microsoft is again using its natural integration with Microsoft Office to offer project management tools that do not require manual mapping. A dashboard view of a project’s progress augmented by a rich variety of metrics, providing a common status window for all stakeholders. This project management based methodology is used to drive the ALM lifecycle.


Towards the other end of the ALM cycle, Visual Studio’s Team Test Edition provides software testers with a wide array of test techniques via its manual, load and web testing tools. The Team Foundation Edition collaborative tools raise productivity by reducing time wasted at meetings while empowering both IT and non-IT staff with universally comprehensible metrics.


Source code control and work item tracking are among the tools used to monitor the work-in-progress state and cost dynamics of software projects. To round out this functionality, Portfolio Explorer incorporates into Visual Studio IDE the project management capabilities of these tools.


It is too premature to judge Microsoft’s ALM system prior to the first release of a full suite in the second half of this year. However, there is no reason to believe that Microsoft’s ALM will be any less of a competitor than its late dark horse entries into other markets.

 
print save email comment

print

save

email

comment

 
 

Search SDA Asia

Free eNewsletter

SDA Asia Magazine Free Download
 
 
 
Copyright @ 2008 SDA Asia Magazine - All Right Reserved Privacy Policy | Terms of Use