Charlie Alfred’s Weblog

A Tale of Three Product Types

Imagine three projects that run concurrently in three different companies which develop and market software-intensive products.

One is technology-centric. Another is application centric. The third is deployment centric

What does this mean?

The following figure summarizes the essential characteristics of the three types:

 

 

A technology-centric project seeks a breakthrough solution to a complex technical problem that has broad utility. GPS receivers, wireless network adapters, and biometrics are all examples of technology-centric developments.

An application-centric project seeks to apply one or more technologies to impove the productivity or enjoyment of a few types of users. For example, a company might:

combine a GPS receiver, color graphic display with touch screen, embedded computer, and street map data to develop a handheld GPS unit.

create a patient monitoring device that can continuously monitor a patient’s vital signs and transfer raw data and alterts to a central monitoring station

integrate biometrics with hand-held, laptop, and desktop computers to provide user authentication.

A deployment-centric project seeks to coordinate the activities and improve the effectiveness of an organization. Examples include departments, cross-functional teams, an enterprise, or a supply chain.

Of course, these three categories are archetypes. There are several additional examples that fit inbetween. One example is an application such as instant messaging, which is targeted at relatively small groups of users. Another is where existing technology must be adapted and improved in order to create a viable use application. Miniaturized video cameras, inserted into catheters can be inserted into a patient’s blood stream to allow a cardiologist to view the status of the inside of a patient’s coronary arteries. In any case, these three archetypes provide three useful points of view about software architecture formulation.

Why are these archetypes significant?

These archetypes are significant because they represent very different situations, and require different approaches to software architecture and project management. In other words, the conventional wisdom that there is a typical software development process is, quite simply, flawed. Let’s use some common metaphors to illustrate why this is true.

Technology-centric projects are like climbing a 200-foot sheer rock face. In both cases, the goal is to discover a solution that overcomes a set of complex obstacles. Experimentation, discipline, persistence, and the ability to cope with side-effects are keys to success. Elegance is nice, but results and urgency dominate.

Application-centric projects are like driving solo from Boston to San Diego this year. Modern applications leverage platforms like Java and .NET, and a host of commercial and open source components and frameworks. Similarly, the quality of both the Interstate Highway System and modern autombiles remove a great deal of complexity (by contrast, consider the same trip 150 years ago in a covered wagon). Many applications deal with minimal levels of variation, and rely on actors, use cases, features, and functional decomposition. In the same way, cross-country drivers expect different states to have similar traffic laws, road conditions, and gas stations.

Deployment-centric projects are like being a manager for a Major League Baseball team. Deployment-centric projects experience high-levels of variability, both across deployment contexts and over time. Similarly, many of the decisions a baseball manager makes are dictated by the game situation and the batter-pitcher matchups. Just as deployment-centric projects must get the most out of the efforts of many individuals in an organization, so must a baseball manager find the right roles for each of his players. A deployment-centric system must accomodate different policies and collaboration styles of its users, just as a baseball manager must find different methods to motivate and teach different players. Finally, a deployment-centric system must interoperate with a wide variety of external systems, just as a baseball manager’s performance is scrutinized by the fans, media, and owners (often not with the same criteria).

So, why do these archetypes matter in the real world?

As organizations and products grow older, they often evolve from one archetype to another. Unfortunately, since this evolution occurs over months or years, organizations tend to cling to their old processes and ways of thinking. And this is where the seeds of woe are sown. Let’s use two examples to illustrate this point.

First, consider a company that is evolving from technology-centric to application-centric. As a technology-centric organization, the primary struggle was overcoming external constraints: logical, electrical, chemical, or mechanical. Experimentation was necessary to discover the solution, and innovation was valued over following the rules. Finally, since the technology usually represented core intellectual property, in-house solutions tended to be preferred over external ones.

Now think about this. How many of the approaches and tendencies that work well for technology-centric development don’t fare as well in an application-centric context? Each of the ones mentioned in the previous paragraph morph from a strength into a weakness:

A focus on constraints rooted in science and math versus user experience and functionality leads to introverted design, which may ignore user needs.

Innovation over rules and guidelines can lead to expediency and a decay of architecture and design rules (making code brittle and hard to understand)

Internal IP leads to prefering to build software in-house instead of searching outside for a viable solution. This leads to non-standard capabilities and more code to write, test, review, and support.

Now, consider a company that is evolving from application-centric to deployment-centric. As an application-centric organization, the primary struggle was developing applications that were fast to learn, helped the users to be more productive, and gave advanced users ways to do sophisticated things and automate repetitive tasks. The Microsoft Office family of applications follow this formula. Now, interesting things happen when an application-centric product evolves into a deployment-centric product.

Consider a source code control product. Initially, these products are developed as groupware applications to focus a limited set of actors (developers, project managers, and quality assurance). Emphasis is placed on use cases and features, such as version history and differences, check in/out, and branch/merge. The system is partitioned functionally; the user-interface, controller, database layer and difference engine are encapsulated.

Over time, as the source code control system gets deployed, users appreciate this functionality, but want more. They want to make the development process run more smoothly by connecting the source code control system to some related applications. These include: defect tracking, programmer IDE, automated build, continuous integration, requirements management, project tracking, and change management. Of course, there are several products in each of these areas, and they all do similar things in a slightly different way. Since there are no industry standards to govern the collaboration with these types of systems, a source code control vendor has little choice but to figure out a proprietary solution that is satisfactory to all parties. After working out an approach with the first vendor of one of these partner applications, what are the odds that this interface will be acceptable to the next vendor of the same application, or the vendor after that?

Variability occurs in other areas, also. In the beginning, source code control systems are used by a moderate number of developers (10-40), who work at a single site. Next, developers want the ability to access the source code control system from home, so thin clients are implemented to support Internet access. Next, companies begin to outsource projects to India, China, and Eastern Europe. Now, there are dozens of developers half a world away from the primary team, making concurrent changes, and requiring fast access to the source code control system.

What are the main implications?

Under these types of stresses, many application-centric systems quickly turn into giant piles of difficult to understand spaghetti. The software becomes hard to modify and brittle. One successful defense is refactoring. Instead of anticipating future changes, the development team addresses the real ones as they come. When a new set of requirements would create an unstable solution, the code is reorganized into a design that would have been appropriate if the new requirements had been anticipated. This approach relies heavily on a thorough complement of automated unit and functional regression tests. These are necessary to make sure that the refactoring process didn’t result in defects in previous capabilites. Unfortunately, refactoring and a full complement of regression tests require a substantial amount of effort to develop and maintain. While the effort and risk are demonstrably less than manual testing or no testing, schedule pressure can undermine the best intentions.

The point here is that things change, in complex ways. Because of the very nature of improving productivity in significant-sized organizations, the architectures of deployment-centric systems will almost always be exposed to greater stress than other types. Refactoring and regression testing are very useful tools, in the same way that cement foundations and cross beams are useful ways to support a house. But if you are building in California and are concerned about earthquake damage, then they might not be sufficient.

A different approach is required, one that helps you to deal with contextual variation. One example of such an approach is the topic of the next entry.

 

 

 

 

 

 

 

 

Advertisements

5 Comments

  1. The classification is great. Naming the context is a great way to communicate and is a must to collaborate.

    The classification of the contexts as
    – technology centric
    – application centric
    – deployment centric

    makes sense, and I do agree that the behaviour changes a lot. What I have been thinking about prior to writing this comment was the names itself.

    Technology and application makes sense, but the “deployment centric” name makes me think each time I read it, as the deployment word is chiseled into my mind meaning something different, which makes me think that even a word I have not heard before might fit better, as it does not try to add a meaning for a word I already have several meanings for.

    I might be the only one who thinks that, but I guess a renaming work (just like renaming components/classes in refactoring) might clarify things a lot. Naming is really one of the toughest parts of defining a concept, though this might also be the best match, just thought I should drop a line about this.

    Comment by Alp Timurhan Çevik — May 10, 2009 @ 5:50 pm

    • Hi,

      I agree with you on deployment-centric. When I wrote this article, I wasn’t entirely happy with “deployment-centric”, for reasons including the one you mention. But I had a hard time coming up with a better name. The big challenge is that the name here needs to convey “the stakeholder experience of the product”, recognizing that these stakeholders are very different from each other. I could not come up with a good, short, way to describe:

      1. Concerns that are *outside* the product or service, but are particular to the environment where it is used, and the perspective of the stakeholders
      2. Concerns that *vary* from one environment to another

      Now, I guess I would use the phrase “context-centric” to describe this. But, I’m always open to other suggestions 🙂

      Charlie

      P.S., Never apologize to being obsessive about names. Communication is essentail to architecture, and the wrong name can convey the wrong meaning or intent. Worse yet, people will recognize the name, and think they know what you mean, and may never ask to clarify.

      Comment by charliealfred — May 11, 2009 @ 10:43 am

  2. Wow loved reading this article. I submitted your rss to my google reader.

    Comment by Buraaxord — November 26, 2009 @ 7:03 pm

  3. i really enjoy going through your posts here and i’ve been watching from a distance and finally felt i should let you know. keep posting. Do you have a RSS feed? I just downloaded bloglines and want to add your blog in there.

    Comment by Fermin Demars — July 17, 2010 @ 9:24 am

    • Yes, there is an RSS feed. In IE there’s a toolbar button to enable it. Don’t know the equivalent mechanism for other browsers

      Charlie

      Comment by charliealfred — July 20, 2010 @ 11:46 am


RSS feed for comments on this post. TrackBack URI

Blog at WordPress.com.

%d bloggers like this: