Home > Articles > Software Development & Management > Architecture and Design

  • Print
  • + Share This
This chapter is from the book

Early Forces in Solution Development

A variety of technical and market forces shape a winning solution. These range from the core technologies to the competitive landscape to the maturity target market. What makes these forces so interesting is that they are always changing: Technology changes, the competitive landscape changes, markets mature, and new markets emerge.

Three particularly influential forces in the early stages of development are the ilities, the problem domain, and the technology base. As shown in Figure 3-1, driving, and being driven by, these forces are the target market, shown at the upper right, and the development organization, shown at the upper left. Product management is shown in the center to emphasize its collaborative, leadership role in resolving these forces.

Figure 1FIGURE 3-1 Forces shaping software architectures


The strength of the affinity that the target market and developers have with various forces is represented by single or double arrows. The final solution, including the marketing and technical architectures, lives in the "space" defined by all of the forces that shape its creation.

The problem domain is the central force in the development of a winning solution. Any given problem domain, such as credit card transaction processing, automotive power systems, or inventory management, immediately evokes a unique set of rules, nomenclature, procedures, workflows, and the like. Included in my definition of the problem domain is the ecosystem in which the solution exists, including customers, suppliers, competitors, and regulatory entities. Understanding the problem domain is a key prerequisite for both the marketect and the tarchitect if they wish build a winning solution. This is why most every development methodology places such a strong emphasis on gathering, validating, and understanding requirements as well as modeling the solution. This is also why effective product development places such an emphasis on the concept proposal and the business plan.

The interplay between the marketect and the tarchitect in this process is quite interesting. Recall from Chapter 2 that the marketect's primary job is clarifying and prioritizing market needs; the tarchitect's primary job is to create a technical solution that will meet these needs. If the marketect is convinced that speed is paramount, as opposed to flexibility or usability, then the tarchitect will make certain choices that emphasize speed. Simply meeting the prioritized requirements, however, is insufficient to produce a successful tarchitecture. For this, the tarchitect must also bring his or her own domain experience to the tarchitectural design.

The requirement of extensive domain knowledge for a tarchitect is so strong that few developers can be promoted to this position until they have considerable experience and skill building systems within the specified domain. My rule of thumb is that, before someone can be considered a tarchitect, he or she must have done one of the following:

Been a key member of a team that has created, from scratch, at least one major system in the given domain and has experienced the effects of that system through at least two full releases after the initial release (three releases total).

Been a key member of a team that has made major architectural changes to an existing system and experienced the effects of these changes through at least two full release cycles after the changes were introduced.

Sometimes "The Hard Way" Is the Only Way

Most of the time the only way to learn a domain is through long-term relationships with customers. Among my responsibilities at a major digital content security provider was the creation of a backend server architecture that supported multitier distribution of software. As I learned the capabilities of the system, I also learned some of the lessons key members of the development team had learned over several years of working with major software publishers.

One of the most interesting lesson lay in the management of serial numbers. As it turns out, almost every major software vendor has a unique approach to managing serial numbers through its sales channel. Some create them in real time. Others create serial number blocks that are distributed according to predetermined algorithms to key channel participants. In this approach, the numbers are used not only for identification of shipped software but also for backend reporting and analysis. Other vendors use variants of these approaches.

Supporting every variant requires close interaction between marketects and tarchitects. In the case of this company, it was also vital to involve professional services, since they were the group that made everything "work" for a customer. It was clear to me that the only way the system could have evolved to support all of these demands was through the long-term relationships established with customers that enabled key team members to learn the problem domain.

You're not an architect in your very first job. You're not an architect after the first release. There is simply no substitute for sticking with a problem long enough to receive and process the feedback generated through customer use of your system. Do this long enough and you may gain sufficient experience to become an architect.

Ilities are the various quality and product attributes ascribed to the architecture. As Bass [98] points out, they fall within two broad dimensions: those discerned by observing the system at runtime and those not observed by observing the system at runtime. The former, including such attributes as performance and usability, are directly influenced by the target customer. The latter, such as testability and modifiability, are secondary attributes that govern the future relationship with the target customer. Because these secondary attributes are often informally specified, if they are specified at all, the discipline in tarchitectural design and associated system construction is critically important.

Care must be taken when the marketecture or marketect routinely accepts lesser ility attributes than those desired by the development team. When a developer wants to fix a bug or improve performance, but marketing thinks the product can be safely shipped without the fix or that the current performance is acceptable, tempers can flare, especially as you get closer to the projected release date. Keep things cool by creating forums that allow both development and marketing to express their points of view. For example, marketing needs to present arguments that a particular choice is "good enough" for the target customer.

I've found it especially helpful to have customers participate in forums. I vividly remember one customer demanding that we allow her to ship a beta version of our software three months before the scheduled delivery date. Our software was a core component to her software. Any delays in shipping our software affected her customers. She readily acknowledged that the beta had many issues that needed to be resolved. However, its value was so compelling and her customer's need was so great that we eventually agreed to let her ship the beta subject to some strict terms and conditions regarding its use and a firm commitment to upgrade the released version when we thought it was ready.

Engineering (and especially quality assurance) needs to make certain that the risks associated with good enough choices are clearly understood. In the example I just mentioned, engineering provided the customer with a very clear assessment of how the product would fail outright under certain usage scenarios. This didn't change her mind—the beta still shipped—but it did enable her to equip her customer support organization with answers should these problems arisen in the field.

As described in Chapter 1, most development teams must make a variety of technical compromises in order to ship the product on time. Managing these compromises is difficult, as most compromises have their most pronounced negative effect in the release that follows the release in which they were introduced. This is another reason to demand that your tarchitect have the experience of two or more full release cycles. Only experience can help you gauge the potential severity of a technical compromise and only a long term commitment to the integrity of the product will make absolutely certain such compromises are removed.

Bug Severities, Priorities, and Normalization

One technique that I have found very effective in managing ilities is to classify bugs by severity and priority. Severity refers to the impact of the bug on the customer. Setting it to a value ranging from 1 to 5 works well, where 1 is a crash with no workaround and 5 is an enhancement request. Priority refers to the importance of fixing the problem. A five point priority scale also works well. A 1 is a bug that must be fixed as quickly as possible—such as one that breaks the build or that is required to satisfy an important customer. A 5 means "fix it when you can."

It is relatively easy to create consistency within your QA organization for severities, because they can be objectively verified. Priorities, on the other hand, are subjective. A misspelling in the user interface may get a 4 for severity, but different cultures will ascribe different priorities to fixing it. Americans and Europeans are happy to give these kinds of bugs low priorities. Japanese customers tend not to be as tolerant and give user interface bugs high priorities. Because of their subjective nature, setting priorities consistently across various members of the team can be difficult.

Fortunately, I learned how to improve prioritization consistency from one of the very best QA managers I know, James Bach. When a code freeze occurred, James would hold a bug review meeting that included all of the major stakeholders involved with the release. In this meeting he would review a sample of bugs (or all of them) to set initial priorities. Because all of the major stakeholders were represented, we could learn when and why support might prioritize a bug higher than product management would or why a senior developer would be so concerned if a certain kind of bug appeared. Although the meetings were rather long in the early part of the QA cycle, they had the advantage of "calibrating" the QA team so that they could more effectively prioritize bugs based on their collective perceptions.

These meetings worked well for our organization because we could quickly come together, review the issues, and move on. They don't work for every team, and when they go poorly a lot of time can be wasted. If you try this approach and find it isn't working, consider an alternative approach that my colleague Elisabeth Hendrickson has used: preset quality criteria.

Preset quality criteria act both as exit criteria and as a prioritization guide. Suppose you define them as MUST, SHOULD, and MAY. Any violation of a MUST is an automatic P1 bug, SHOULD violations became P2s, and so forth. You then have to define the various criteria. You might define MUST as follows:

  • The system MUST support 100 concurrent users.

  • The system MUST retain all data created in a previous version throughout an upgrade.

  • The system MUST present an error dialog only if the dialog contains directions on how the user can fix the problem.

One advantage to this approach is that you get people thinking about priorities (both market and product) long before quality assurance is initiated. Bugs are also managed by exception, with the review committee meeting to handle those that for some reason don't seem to match the preset quality criteria.

The technology base dimension includes the full suite of possible technologies available to the development team. These include the languages and compilers, databases, middleware, messaging, as well as any "uber-tarchitecture" associated with the system—a technical architecture that prescribes the basic structure of many classes of application and that is delivered with an extensive array of development tools to make it easy for developers to create applications within it. Examples of uber-tarchitectures include J2EE, CORBA, Sun ONE and Microsoft .NET (all of which are also marketectures, depending on your point of view).

Choices made within the technology base must support the tarchitecture as motivated by the problem domain. This can be challenging, as developers are people with their own hopes, desires, preferences, and ambitions. Unfortunately, "resum -driven design," in which developers choose a technology because they think it's cool, is a common malady afflicting many would-be architects and a major contributor to inappropriate architectures. Marketects are also people, and "airplane magazine market research" becomes a poor substitute for the hard and often mundane but necessary market research and decision making that lead to winning solutions.

I have intentionally simplified my discussion of the early forces that shape a winning solution. If you were to ask me about a discrete force not already discussed, such as competitive pressures or requirements imposed by a regulatory agency, I would lump its effect with one associated with the problem domain, the ilities, or the underlying technology. This process is not intended to diminish the effect of this force in your specific situation. To consciously do this would be dangerous and would certainly miss the point. It is imperative that you remain vigilant in identifying the most important forces affecting both your marketecture and your tarchitecture.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020