all bits considered data to information to knowledge


Quality Attributes: either binary or quantifiable

Architectural document that reads like a promotional materials always makes me wonder... What exactly does the author mean by "easy to maintain"? Does adjusting mere 20+ configuration files on several machines in a cluster, and umpteen start up parameters for the dozens of processes qualify? How about going through several tabs with dozens of conflicting options on every instance? "An easy" is in the eye of the beholder, architects must do better than that.

In 1983, Tom  DeMarco in his seminal work - Controlling Software Projects: Management, Measurement and Estimation - famously remarked: "You can’t control what you can't measure"

This rhymes with a similar sentiment expressed by Lord Kelvin almost a hundred years earlier in somewhat more convoluted form characteristic of the times:

"...I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be."

-Baron William Thomson Kelvin
From 'Electrical Units of Measurement', a lecture delivered at the Institution of Civil Engineers, London (3 May 1883), Popular Lectures and Addresses (1889), Vol. 1, 73. Quoted in American Association for the Advancement of Science, Science (Jan-Jun 1892), 19, 127.

This correlates strongly with system quality attributes used to control system architecture development process. Any quality attribute to which the architecture must conform has either to be measurable (numbers!) or be binary - yes/no - in nature, relative terms just would not cut it (easier? more flexible? robust-ier?). If you state that the system is "adaptable" - it would mean that it is designed to accommodate some anticipated changes; it does not mean that it can swallow any change that comes after the system was designed; the value of such an attribute could only be relative as it provides no ways to quantify it. On the other hand, if "responsiveness" is the desired quality attribute then it has to be measurable (unless you are talking about Leibnitz’s monads, that's it ); milliseconds response time per user per concurrent users might be one example...

There unquantifiable adjectives and/or adverbs used in quality attributes must be kept to an absolute minimum, and be qualified (e.g. "adaptable within current technological paradigm")


Enterprise Architecture als Das Glasperlenspiel

The opus magnum by Hermann Hesse - Das Glasperlenspiel - comes to mind after three days of Oracle Enterprise Architecture training… All too present is the danger of disappearing into extremely complex but ultimately manageable world of technological abstractions while shunning crass and messy world of business.

The primary goal of Enterprise Architecture is to build coherent enterprises, not better IT systems.

- Pallab Saha


Enterprise Architecture ≠ IT Architecture

By Pallab Saha from the National University of Singapore, an expert in Government Enterprise Architecture

Six Reasons Why EA Should NOT be Assigned to the IT Department

6. EA ≠ IT Architecture

5. True EA leads to redistribution of authority, which is beyond CIO jurisdiction.

4. EA value proposition (i.e. standardization vs. innovation) is solely business realizable.

3. The primary goal of EA is to build coherent enterprises, not better IT systems.

2. Synthesis takes precedence over analysis.

1. EA failure is an organization failure, not an IT failure.

These points were taken verbatim from Pallab Saha's illuminating post on LinkedIN group - The Enterprise Architecture Network.


Putting “E” in ESB

Forrester's survey data shows that service-oriented architecture (SOA) still has strong penetration and high satisfaction rates. Even though today's headlines focus more on cloud computing, mobile applications, and social networking, enterprise interest in SOA-related products remains significant. However, among the four major SOA specialty products, enterprise interest has shifted away from enterprise service bus (ESB) products.

Here's a shocker - Enterprise Architecture is hard.

I believe the following are the reasons behind "interest in ESB shift" among the enterprises.

ESB is the heart of SOA, and not many enterprises are willing to undergo "heart surgery" without compelling reasons to do so. For better of for worse, ESB is a "big bang" concept - unless the entire IT eco-system is re-arranged around this fundamental concept there will be no sizable benefits to realize; given a chance, enterprise always will opt for incremental change.

ESB takes concept of software re-use to its logical conclusion, and requires shift in thinking on how software is designed, constructed and integrated. The re-use promise of object oriented paradigm got a lot of attention but ultimately failed to deliver, mostly for reasons that had nothing to do with software engineering.

ESB is hard. No matter how many "SOA for dummies" books are published, the actual implementation is either technologically challenging or expensive, or both. Explaining its benefits to CFO is like explaining theory behind acetaminophen's physiological effects to a five-years old with high fever, except that you do not report to a five-years old.

So, what's the prognosis? The idea of ESB is here to stay; the concept of universal communication channel, its orchestration capabilities, its promise of services reuse make perfect business sense. The actual packaging will have to change ... not unlike bubble-gum flavoring in bitter medicine one has to swallow for his own good.


Microsoft Application Architecture Guide, free!

As the saying goes, the best things in life are free! If you are engaged in designing applications that - at least partially - utilizes Microsoft technologies, this free book provides a treasure trove of information:

Microsoft Application Architecture Guide, 2nd Edition

  • Understand the underlying architecture and design principles and patterns for developing successful solutions on the Microsoft platform and the .NET Framework.
  • Identify appropriate strategies and design patterns that will help you design your solution's layers, components, and services.
  • Identify and address the key engineering decision points for your solution.
  • Identify and address the key quality attributes and crosscutting concerns for your solution.
  • Create a candidate baseline architecture for your solution.
  • Choose the right technologies for your solution.
  • Identify patterns & practices solution assets and further guidance that will help you to implement your solution

Design vs. Architecture

Some time ago I came across a discussion posted in a LinkedIN Enterprise Architecture group; it was about how (if) design is different from architecture. The question kept bugging me for a while - I felt that there is difference but could not quite formulate my thought. Until today, that is 🙂

The break trough came while reading Software Systems Architecture by Nick Rozanski and Eoin Woods

Design refers to functional composition of the system, while architecture is also concerned with behavioral aspects of it. Therefore, architecture includes the design component, and extends it by adding quality attributes.


Do system architects dream of business analysts?

The following represents my answers to the questions posed by a Ph.D. aspirant in search of the thesis   🙂

1. Q: Do you agree that architecture design and requirements elicitation are usually in parallel or have a big time overlap? In other words, Architectural design usually starts before requirements elicitation ends, and usually a big time overlap exists between these two activities.

 A:  No, requirements’ gathering starts first. Even a simple sentence stating “I’d like to have a system that..” constitutes a requirement in my opinion. There are aspects such as existing Enterprise Architecture that require Solution Architecture to align with; it might exist prior to requirements gathering for a specific software-intensive solution.

2. Q: Do you agree that when performing architectural design, making some decisions depends on the outcome of some other decisions? I other words, a sequence/order exists for the set of architectural decisions need to be made.

 A:  Yes. Some of the decisions predicated upon the others, therefore there is a hierarchical structure, a decision tree.

3. Q: Do you agree that, in most cases, for a particular architectural decision, only a [s]mall portion of the whole requirements actually influences the decision making? In other words, there is mapping exist from the architectural decisions you need to make and the requirements required when you make those decisions.

 A:  No. There are architecturally significant requirements, requirements that affect the decision only marginally, and everything in-between. Moreover, they affect the solution architecture on different levels: system architecture, software architecture, information architecture, infrastructure architecture etc.

4. Q: Do you agree that requirements engineers usually do not know clearly what items/aspects of requirements are architectural significant (i.e., it is not easy to distinguish architectural significant requirements from normal non architectural significant requirements)? Thus, they may ignore/miss some items of requirements (some of them may just look like trivial details) that are actually architectural significant during their requirements elicitation.

 A:  Yes, to certain extent. Not being trained to architect a system, business analysts (the “requirements engineers” in your question) cannot decide which requirements are architecturally significant, and which are not. It is up to solution architect to reconstruct the missing links from the requirements gathered like a paleontologist might reconstruct a dinosaur’s skeleton by just a few broken bones

5. Q: Do you agree that requirements engineers usually are not aware of which items/aspects of requirements are required urgently by architects and which items/aspects of requirements can be scheduled a bit later to elicit? Thus, they may first elicit the requirements required for making the decisions in the tail of the decision making sequence, and schedule the elicitation of requirements required for the architectural decisions in the front of the decision sequence to the end of the requirement elicitation phase.

 A:  Ditto. See answer to Q.4

6. Q: Do you agree the following statement: If the requirements engineers are informed of what items/aspects of requirements are required and when they are required by the architects for making architectural decisions, the requirements engineers will be able to properly schedule their requirements elicitation activities and elicit the required requirements in enough detail and precision. So they will have higher chance to provide the required requirements to the architects before the architects make those architectural decisions.

 A:  Yes. Business Analysts (aka “requirements engineers”) need to work with all stakeholders, including Solution Architects, to solicit and refine requirements for a software intensive system


Extensible Architecture

Q: How to prove to a client that the system is extensible? (an actual question...)

Nail down the client’s definition of extensibility first; it might be possible that her ideas are quite different from yours. Once you are on the same page, make sure she understands the limitations of extensibility and ramifications of thereof; for example, she might want a Cadillac but only has a Yugo budget.  

Designing an infinitely extensible system requires both time and budget of corresponding proportions…

 In a single sentence: an extensible architecture would have a modular structure as well as defined set of API(s) for integration; current paradigm leans towards loose coupling, usually via Web Services (latency, concurrency and other inherent limitations need to be carefully considered).


Taxonomy and Ontology in Systems Architecture

Taxonomy and ontology are bread and butter of every software system architecture. And yet the very people practicing it barely can agree upon what they actually mean!

Some think these concepts to be interchangeable; some (myself included) think  that taxonomy is but a classification (usually in a parent-child hierarchical relationship, e.g. Linnaen classification) , a component of ontology which deals with domain definition and more complex semantic relationships within.

And then I come across a definition of Architectural Taxonomy: "A methodology for organizing and categorizing of architectural artifacts" quoted in Roger Sessions' book Simple Architectures for Complex Enterprises (from Carnegie Mellon University collection of definitions).

Unless they mean Architectural Ontology, I fail to see how a simple hierarchical classification can account for non-linear and non-hierarchical relationships of various architectural artifacts, not to mention their dynamics...


Dark waters and thick clouds of the skies…*

Will cloud change the ways we architect software?

Despite all the hype, cloud computing is little more than ability to procure computing capacity on demand, platform as a service; it is virtualization on steroids...
It holds the same promise as Internet had in the beginning  - levelling of the playing field. Instead of buying expensive hardware and software one could configure a whole farm of servers within an hour, pay only for what it is being use, and shut down when no longer needed: no unused licenses, no hardware to auction. Ultimate flexibility.

This also would give rise to unique architectural solutions..Imagine, that your system decides that it needs to increase computing or storage capacity to meet an increasing demand. In physical world this would mean buying and configuring a server, plugging it into network, installing all the software - and this would  involve someone doing the actual work... In the cloud all of this can be done automatically through API.
A software system that grows, shrinks and configures itself... This what I call paradigm shift!

SOA yields itself very nicely to the cloud, one might say this is a marriage made in heaven; ultimate in distributed computing, a first class cloud citizen. Imagine a self assembling software where kernel system discovers services, and strings them together into useful processes according to some vaguely spec'd needs... I can dream, can't I?

*He made darkness his secret place; his pavilion round about him were dark waters and thick clouds of the skies. Psalm 18:11