Part 3, ASRs and Riding the Wave of Change

One of the problems with life is dealing with change. Nothing is static. Everything is constantly changing. While that has always been true, the pace of change has accelerated in modern times. The volume of changes that seem to have some impact on us has gone up, and the awareness of change has intensified. We are constantly told that newer and better stuff is now available, to replace the stuff we just bought yesterday, which we may not have had a chance to use yet. We live in an era where we now measure things in internet time. Stability and constancy are old-fashioned virtues. This is a hallmark of technology and is particularly true when dealing with computers and software. Open source software is no exception; in fact, quite the opposite is true. Drupal and WordPress have different schemes for how they drive change into their user communities and offer different facilities to their users to comprehend and administration change. These differences are not inconsequential. 

In this post I’m going to discuss a new viewpoint on requirements that I haven’t mentioned before: architecturally significant requirements (ASRs); and I’m going to cover a few hot button elements on my evaluation of Drupal and WordPress for architectedfutures.net.

What Are Architecturally Significant Requirements (ASRs)?

Architecturally significant requirements are those requirements that play an important role in determining the architecture of the system.  Such requirements require special attention. Not all requirements have equal significance with regards to the architecture.

From: Concept: Architecturally Significant Requirements

ASRs are either functional or non-functional requirements (see part 1). What makes them significant is the impact they have on the architectural solution. If the ASRs aren’t satisfied the customer, the user, isn’t just inconvenienced, the solution doesn’t work; it doesn’t do the job. The architecture is wrong for the problem. It doesn’t provide a solid and stable solution, or it fails to please the user in how it achieves its function. Deciding what is architecturally significant is a matter of skill and judgment. Determining how well a particular solution fills requirements, especially before the fact (a priori), is again a matter of skill and judgment.

ASRs are typically defined in terms of key requirements that are the motivating factors in the design of the architecture for the system.  Some of these requirements are functional. A lot of these requirements are qualitative. But what does that mean? In the architecture of buildings there is a significant difference between a church, an office building and an airplane manufacturing facility. That’s functional. But the difference between a church, a chapel and a cathedral isn’t so much functional (putting aside the aspect of scale), it’s qualitative. Or compare the differences between a half-dozen major office buildings, or compare a half-dozen architect designed 3 bedroom, 3 bath, two car garage houses. The differences in the architecture of the office buildings, or the houses, isn’t functional so much as qualitative. The same is true of other systems, including software systems and social systems. “What is it?” tends to be about function. The way it gets done, the style, the attitude, tends to be qualitative. And quality matters. Quality can drive durability. Quality can drive satisfaction.

Architected Futures Community of Practice ASRs

For my evaluation of Drupal versus WordPress (versus whatever) as the technology platform for the Architected Futures Community of Practice (AFCoP), the object being architected is AFCoP, not WordPress or Drupal. I am not writing the specifications for, nor am I designing, Drupal or WordPress. So, I am not trying to define, nor am I overly concerned with WordPress or Drupal ASRs. I am concerned and focused with AFCoP ASRs.

What I’m saying is that things exist in layered, compositional hierarchies. At some point we draw a line around something and that becomes the object of focus. The architected object. The environment it exists in is outside of the object. It may have interactions with other things in that environment, but they are external to the object of concern. You don’t really design your environment. You come to grips with it; you learn to deal with it. As you look at what is inside you decompose the object into parts. If the parts are novel, you may need to design (architect) them. As you do that, you decompose those parts into other parts. If the parts aren’t novel, you can either design new parts, if you feel the need, or you can obtain pre-fabricated parts from a catalog; or you can do a little of each by making adjustments to catalog parts. This is the internal mechanics of the object. However, at some point, you become unconcerned with the details of how the remaining parts work. It stops being a primary issue with respect to operation of the object you are concerned with. The parts just need to do a job. Catalog parts are fine. You don’t want to design how they do that job, as long as the job gets done. If one part doesn’t work to your satisfaction, you swap it out and get another part.

There are two layers of architected entities that I am primarily concerned about in the creation of my community of practice.

1. The first, outer layer, is AFCoP – the community of interacting people. This is essentially the architecture of a social system, a Community of Practice. That community will exist in an environment of planet Earth, human beings, the internet, etc. The components involve topics, interaction policies, the involved people, groups and sub-groups, technology for communicating, etc.
2. The inner layer of concern to me is the architecture of the technology platform to support the Community of Practice. The technology platform architecture is a part of the Community of Practice architecture. The platform will be architectedfutures.net. The environment for architectedfutures.net will be the AFCoP community, a hosting service, the internet, external support services, etc. The components of architectedfutures.net will include a lower level (nested) technology platform (WordPress or Drupal), a particular set of add-on modules, etc.

The AFCoP technology platform, architectedfutures.net, is an ASR for AFCoP.  How well the community is able to interact is critically dependent on the facilities provided by the technology platform. To meet that ASR architectedfutures.net is being designed specifically to meet the needs of AFCoP. This won’t be a social network site for a church group or a book club. It has special requirements to support the mission and focal interest of the Architected Futures™ community. If certain features, some functional, some qualitative, aren’t there, then the success of the community will be jeopardized. In a similar way, the choice of base platform (Drupal, WordPress, some other package, custom code, etc.) is an ASR for architectedfutures.net. The structure, the support requirements and the way the functional capabilities are provided by the infrastructure is a critical factor in the success of architectedfutures.net. But it isn’t all or nothing. The Drupal and WordPress platforms are being evaluated as candidate components to provide the base for architectedfutures.net‘s architecture. Some tasks can be done with either platform, although they may vary somewhat in how they are done. Other tasks or functions aren’t so benign. Their presence or absence may be critical to the community, or the way they are achieved may have a major effect on the community. That impact makes those qualities of the infrastructure architecturally significant to the community of practice. Those are the key qualities I want to focus on in terms of my decision.