|
...needs), reducing time to market.
Background
Several years ago, a consortium of software industry leaders--including IBM, Rational * Software (before its acquisition by IBM), and Microsoft--began exploring ways to help organizations repurpose software investments. In this exploration, it was determined that software entities need to be named, organized, reviewed, and reused to improve the return on the investment in them.
The consortium began to describe these software investments as software assets. This led us ultimately to create standards for asset packaging formats and then to develop tools and processes to work with assets throughout their life cycle. Although we found that assets take on many shapes and sizes and are used in multiple roles throughout the development life cycle, we found similarities among asset types. This made it possible to consider using automation with reusable assets.
Models, a reusable asset, provide a unique opportunity to mitigate complexity, improve consumability, and reduce time to market. We proceed by addressing each of these areas.
Complexity
The demand for more sophisticated solutions is one impetus to the increase in complexity of our software development projects. Increasing complexity is also driven by the pervasive nature of software in today's business and government processes. With software reaching into all aspects of business and government, software design and testing have become two of the critical factors to address the inherent complexity.
Some see complexity in software stemming from the variety that software organizations face--the variety of methods and tools available, the variety of software and hardware, and the variety in skill sets and organizational structures. The value of decomposing the technology stack that organizations use to deliver solutions can be argued, but with that comes an increasing number of elements and combinations. All of these factors--methods, tools, software, hardware, and organizational structures--add to the increasing complexity of software.
In The Economist, (1) n article on managing complexity outlined some of the well-known software project failures and posited that a fundamental reason for such failures is the lack of tools for developers and management that scale to the level of complexity required by today's solutions. Specifically, poor software design was identified as a fundamental element of this failure: As software has become more and more pervasive in business and government, and more complicated, the impact of poor software design has been steadily growing.
Consumability
From experience we learn that the longer it takes to locate, evaluate, use, and extend an asset the more difficult it is to preserve its value. Many of us have experienced the frustration of trying to find and understand work someone else performed. If it takes us longer than what seems reasonable, then we often look elsewhere or stop looking and re-create the content ourselves.
There are no hard-and-fast rules about how long that time is, but some common sense prevails. If we are looking for a model that describes the architecture for a system that our team will build for the organization, it is reasonable that we may take several days or more to find and evaluate it. Conversely, if we are looking for a sort routine, then we are less inclined to spend such a lengthy time. Finding the asset is only part of the problem. Understanding its purported solution and its relevance to the context at hand is another challenge to reusing it. The ability to comprehend what has been created and shared is the next major hurdle. There is a balance between complexity and comprehension, and often solutions are provided that are complex and difficult to understand. In the end, this can be summarized as consumability and ease of use.
Poulin points out that one aid to achieving consumability is to organize the assets in a consistent manner. (2) He notes from a study on the topic that using a standard layout lets a potential reuser quickly scan the important aspects of a component, such as text descriptions, pseudo-code, illustrations, and implementation information. More is said on this topic later in the paper.
Time to market
The notion of time to market is comprised of the individual daily wins an organization makes in its software development process. This includes the notion of time to value, a test that reusable assets must pass constantly to ensure their investment. Time to value means discovering and understanding the right model for the relevant context in a timely manner to achieve productivity improvements. It is directly impacted by the amount of time required to find the right model, but even more so by its reusability. Two factors that make an asset reusable, impacting its time to value and thereby affecting the organization's time to market, are its complexity and its comprehensibility.
There are few metrics dealing with either of these two factors. Quantitative metrics include the MacCabe Cyclomatic Complexity metric (3) and the Halstead Software Science metrics. (4) These metrics focus on program logic, structure, and lines of code, but they do not directly translate to the complexity of a model asset. Several studies that focused on comprehension concluded that if users were presented with consistently structured information and artifacts regarding assets, the comprehensibility of those assets improved. (5,6) We can conclude that if an asset is truly comprehensible, offers minimal complexity, and solves a recurring problem, and if the consumer of the asset can discover it quickly, then that asset has its best chance at providing value in a timely manner. It is the aggregation of many time-to-value wins that can ultimately affect time to market.
Show me the money
Walker Royce describes the context within which asset reuse flourishes (7): In general, things get reused for economic reasons. Therefore, the key metric in identifying whether a component is truly reusable is to see whether some organization is making money on it.
In our corporate zeal to develop technologies and solutions, we often become enamored by technical brilliance. The cycle for innovation should always be tempered by value to the customer and to the business. In Model Driven Development ** (MDD **) work, the same holds true for the use and reuse of...
NOTE: All illustrations and photos
have been removed from this article.
More articles from IBM Systems Journal
Model driven development for business performance management., July 01, 2006
UML 2: a model-driven development tool., July 01, 2006
Feature-based survey of model transformation approaches., July 01, 2006
Using logical data models for understanding and transforming legacy bu..., July 01, 2006
Rational software architect: a tool for domain-specific modeling., July 01, 2006
Looking for additional articles?
Search our database of over 3 million articles.
Looking for more in-depth information on this industry?
Search our complete database of Industry & Market reports by text, subject, publication
name or publication date.
About Goliath
Whether you're looking for sales prospects, competitive information, company
analysis or best practices in managing your organization,
Goliath can help you meet your business needs.
Our extensive business information databases empower business
professionals with both the breadth and depth of credible,
authoritative information they need to support their business
goals. Whether it be strategic planning, sales prospecting,
company research or defining management best practices -
Goliath is your leading source for accurate information.
|
