On the plane or in the plane?

…I’m getting IN the plane! IN the plane! Let Evil Knievel get ON the plane! I’ll be in here with you folks in uniform! There seems to be less WIND in here!
(George Carlin commenting on airport announcements)

Words have meaning, but we sometimes use them in a casual manner. George Carlin made a career pointing out absurdities from casual usage. Likewise, lawyers have good days or bad days depending on the precision or lack of precision in the use of language. A recent article on TechRepublic caught my eye for that same reason: if “Poll: How much of your logic is in services?” is taken literally, there’s a huge problem.

Having your business logic “in” services as opposed to “behind” services means you’ve either limited your flexibility or you will violate the “Don’t Repeat Yourself” (DRY) principle. The principle of interoperability that underlies service orientation is potentially impaired if the application logic is tightly bound to the communication method that exposes it. Last month, Davy Brion complained about the use of WCF services as an intermediary between a web front end and the back-end of the application. He identified the performance impacts as well as the increased complexity of both development and deployment. However, if your non-UI logic is inseparable from the service itself, you cannot avoid this without redundant code. The only way to expose functionality via multiple methods (e.g. REST and SOAP services, direct connection, message queues, etc.) when working in this manner is to duplicate the functionality for each method – not an ideal situation.

A more flexible architecture can be achieved using a message-oriented business layer that can be wrapped by one or more services or consumed directly. Internal clients that are deployed concurrently with the back-end can use the “native” message format, either by directly referencing the business layer (for a web application) or through a service facade (for Smart Clients, SharePoint web parts, etc) as may be appropriate. External clients can be handled via strictly versioned services that translate to and from the canonical format. This strategy allows not only controlled versioning, but also the ability to provide multiple endpoints for a unified code base. Having only one version of business logic should yield a far more robust system than one where the same business task is implemented multiple times.

Gods and Mortals, Part 2

The animation at the right depicts the culmination of an illustrious career. Obviously, it was not a happy ending. Vice-Admiral Sir George Tryon, Knight Commander of The Most Honourable Order of the Bath and Commander in Chief of the British Mediterranean Fleet, secured his place in history by giving an ill-considered order and then refusing to have it questioned. His stubbornness cost 358 lives (including Tryon himself), one battleship sunk, a second damaged and the loss of his reputation.

Much has been said about George Tryon’s charm of manner, and the rest of it, but in truth he was, at any rate when officially engaged, a very brusque and dictatorial man. Unfortunately he was a ‘viewy’ man too, a man of theories…
(A description of Vice Admiral Sir George Tryon, from a July 1893 article in Society Journal Talk via Wikipedia)

On June 22, 1893, Vice Admiral Tryon ordered the eleven ships under his command to steam in two columns towards the shore. The two columns were to turn inward, reversing their direction of travel and proceed out back out to sea. However, insufficient space was left between the two columns for them to safely execute the turn. An officer questioned the spacing and was sent packing. When the officer leading the column opposite Tryon’s, anticipating the impending disaster, was slow to begin the turn, the signal “What are you waiting for?” was sent. This public reprimand yielded compliance with the order and the debacle was set in motion. Only when the collision was both imminent and unavoidable did Tryon attempt to alter course. The lead ships of the two columns, Victoria and Camperdown, collided, causing Victoria to sink with the loss of over half her crew.

Prior to the collision, George Tryon’s career had been spotless. He had risen steadily through the ranks and been knighted for his service. Most ironically, he was a progressive leader and extremely active in promoting initiative in his subordinates. Unfortunately, his surly manner toward those same subordinates led to their being terrified of him.

In “Gods and Mortals, Part 1”, I outlined the importance of collaborative design over attempting to dictate. The point of this little history lesson is that actions speak louder than words. Giving lip service to collaboration and challenging your assumptions is not enough. You must actually be open to suggestions and questions, welcoming them as an opportunity to teach and learn. The more skillful you are, the less likely people are to challenge you. The less likely people are to challenge you, the more likely you are to need that challenge. The last thing you need is to discourage those who may keep you from wrecking your career.

Gods and Mortals, Part 1

I first witnessed this early in my career when “the architect” would fly into town for two days every few weeks and diagram the architecture for the upcoming application on a whiteboard. Then the architect would fly out of town and developers would fire up IDEs to implement the architecture.
(K. Scott Allen, from “Whiteboard Architecture”)

The discussion I wish to provoke is: Is it the sole responsibility of the software architect to provide the architecture?
Or is it that the architect is best competent, skilled, verbal, and positioned to help the team (or organization) to produce the most appropriate architecture?
(Ilan Kirschenbaum, commenting on “Architecture versus Design”)

It’s easy to accumulate a backlog of ideas for posts, particularly when you write in your spare time. This one has been waiting in the wings for a while, to be forced out onto the stage by Ilan’s comment on my last post. It’s one I should have addressed a long time ago, because it touches on one of the biggest threats to software architecture: some of those who call themselves architects.

“Ivory Tower Architects” are a long standing embarrassment to the discipline. Likewise, “Architecture Astronauts” and those in love with patterns for patterns’ sake are frequently used to justify the opinion that architects provide no value. Worst, in my opinion, are the Olympians, descending to the mortal realm to dictate to the lower beings. Alone, or in combination with the above types, the “God of Architecture” is particularly adept at alienating the rest of the development team. This alienation leads to ignoring the need for architectural design, or hoping that it will emerge in some coherent form, to the detriment of the product and its users.

In “Agile Architect – What is it?”, Ilan outlined a more collaborative role for the architect:

Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)

The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.

The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.

In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.

I strongly agree. Leadership (paired with responsibility) is necessary, but a more inclusive approach makes sense from several perspectives:

• Understanding – When the other members of the team are involved in the design process, they should gain a deeper understanding of the architecture (knowing both the “whats” and the “whys”) than would be the case if the finished product were deposited in their laps.
• Ownership – Participating in the design should also engender ownership on the part of the team as a whole. People tend to be less resistant to that which they own as opposed to that which is imposed on them.
• Evaluation – The architect gets the opportunity to gauge the skills of the rest of the team and they get a better appreciation of the architect’s abilities as well. This should foster mutual trust.
• Training – Involving the team in the design of the architecture is valuable training. Team growth should be seen as a positive.
• Quality – This applies in two ways. First, a fresh set of eyes is likely to spot issues regardless of the item being tested. Ideas that survive the team approach are likely to be durable ones. At the same time, you gain the advantage of multiple skill sets. It’s unlikely that any given architect (or anyone else for that matter) is universally skillful. Working collaboratively allows you to leverage the strengths of the entire team.

The last bullet point cannot be over-emphasized. Although he was discussing enterprise architecture, Tom Graves made an important point in “Analyst, anarchist, architect” regarding the applicability of the Hegelian triad of thesis, antithesis, and synthesis to architecture:

…the antithesis is not a negation of the thesis, but a challenge to the assumptions on which the thesis is based – which then leads to a synthesis that makes real practical sense.

It’s not impossible to achieve that challenge to your assumptions when working solo, but it’s far from easy. I’d argue that one characteristic of a good architect is making efficient use of available resources. In my opinion, using the team to improve the quality of the architectural design as well as their understanding of it sounds like an efficient use of those resources. In the words of Roman philosopher Seneca the Younger: “Even while they teach, men learn”.

Architecture versus Design

There was interesting debate on what is an architect, the difference between design and architecture (no one really knows…
(Ilan Kirschenbaum, discussing a meeting of the Software Craftsmanship in Israel group)

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
(Grady Booch, as quoted by nearly everyone)

In the inaugural post of Form Follows Function, I noted the definition of architecture that I felt best applied across the realms of Application, Solution, and Enterprise Architecture. While researching the post “What’s driving your architecture?”, I found considerable discussion of the difference between architecture and design (in the sense of design decisions that are architecturally significant versus those that are not). Although the distinction might seem to be academic at first glance, it cuts to the heart of questions around the value of architecture and architects, particularly under Agile processes. This makes the confusion alluded to above by Ilan Kirschenbaum doubly worrisome.

Simon Brown, building on Booch’s comment above, provides important insights on the concept of design in “Disambiguating architecture”. Design “…exists to resolve a force on the system”, where force represents “…cost, scope, resources, timescales, requirements – anything you wish to take into consideration as part of your design selection”. He also notes that “…a design is one of a number of possible choices for resolving a particular force on the system”. Thus design, architectural or not, can be defined as making the optimal choice to satisfy the various forces impacting the matter at hand.

Rick Kazmon and Amnon Eden, writing for the Carnegie Mellon Software Engineering Institute, identified locality as the defining characteristic of architectural design in their article “Defining the Terms Architecture, Design, and Implementation”. Non-local specifications, applying to the system as a whole, constitute architecture in their opinion. According to Kazmon and Eden, “More generally, for each specification we should be able to determine whether it is a design statement, describing a purely local phenomenon (and hence of secondary interest in architectural documentation, discussion, or analysis), or whether it is an instance of an underlying, more general rule”.

Eden and Kazman, joined by Yoram Hirshfeld, further expanded on this definition in “Abstraction Classes In Software Design”, published in IEE Software Vol. 153, No. 4 (Aug. 2006). The authors identify global design decisions as strategic and local design decisions as tactical:

Strategic design statements [11] articulate design decisions that determine the primary behavioural and structural properties of a program (software system). Strategic decisions address global, system-wide concerns and carry the most consequential implications. Strategic decisions include the choice of programming paradigm [36] (‘object-oriented programming’), architectural style [17] (‘pipes and filters’), application framework [24] (‘Microsoft Foundation Classes’), component-based software engineering standards [40] (‘Enterprise JavaBeans’), and design principles (‘universal base class’), as well as assumptions that may lead to architectural mismatch [18] (‘The Softbench Broadcast Message Server expected all of the components to have a graphical user interface’) and law governed regularities [28] (‘every class in the system inherits from class C’). Because of the consequences they carry, Strategic decisions must be made early in the software development process and should be established explicitly before any detailed design is carried out.

In contrast, Tactical design [11] statements articulate design decisions that are concerned with a specific module. Tactical decisions often describe a pattern of correlations between one collection of modules (objects, procedures, classes etc.) and another. Intuitively speaking, Tactical statements are ‘local’ in the sense that their scope is limited to some part of the program and not outside it. Tactical decisions include the choice of design patterns [16] (‘Factory Method’), refactorings [15] (‘Replace Conditional With Polymorphism’), and programming idioms [5] (‘counted pointer’), and usually are taken much later than strategic design decisions in the software development process.

Although I broadly agree with the general rule of global = strategic and local = tactical, it should not be considered an absolute. It is possible for one segment of a system to have aspects that strongly influence the overall architecture (justifying Booch’s criteria for significance). This is the reason that I do not hold the opinion that functional requirements are design and non-functional are architecture.

Arnon Rotem-Gal-Oz, architecture manager at Nice Systems, identifies several aspects of architecture in his presentation “Software Architecture”. Architecture comprises the major components of a system; their relationships and interactions. Data and behavior of these major components is only relevant to architecture from the point of view of the interactions between these components. Like Booch, Rotem-Gal-Oz characterizes the architecture as being the most difficult parts of the system to change. Like Eden, Kazman, and Hirshfeld, he defines architecture as the design decisions that must be made earliest in the process.

The value of strategic, foundational design decisions should be obvious. Since these aspects of the system are both difficult and costly to change, there should be considerable incentive to make optimal choices. As noted by Kevlin Henney in “What is Software Architecture?” on developerFusion:

The issue is not whether or not a system has architecture, but whether its architecture is good or not. All systems have architecture, whether intentional or accidental, explicit or implicit, good or bad – even “no architecture” systems have architecture!

Having related architecture to cost of change, we have a simple way of evaluating architectural quality. It is not that a good architecture makes a system cheap to create; it is that it is also cheap to evolve. In other words, a good architecture is one in which the significance of design decisions is minimised. You are free to change many aspects of a system without the fear that such changes are challenging, costly or create a cascade of bugs. A good architecture is therefore a sustainable one.

Given the criticality of these design decisions, it makes little sense to leave them to chance. Sustainable, flexible architecture is unlikely to emerge organically. Sufficient planning and coordination will be needed from someone in the architect role (regardless of whether the role is full or part-time). Localized design decisions can then be made within that framework in a decentralized manner.

Occasionally I hear people still raising the agile mantra against Big Design/Requirements Up Front. The thing is that Agile Manifesto never said to intentionally bury your head in the sand with regards to the purpose of the system. It was a push-back against spending months in analysis without anything but documents coming out, but the goal was to reach a middle ground. Nobody ever said “no design up-front” or “no requirements up front”.
(Udi Dahan from “A CQRS Journey – with and without Microsoft”)