Software Architecture Assessment

Assessment of software architecture is necessary to judge its utility and applicability to the goals a system aims to achieve. Every architecture design should be assessed by a non-partisan resource, but this practice has been adopted only at organizations with a very mature software engineering processes. There are no industry wide accepted methods for evaluating software architecture, but the Architecture Tradeoff Analysis Method (ATAM), developed by the SEI, is a well structured & rational approach for conducting architecture assessments.

Benefits of a structured tradeoff analysis method

The principal benefit of the Architecture Tradeoff Analysis is an ability to see if a proposed overall software structure will live up to the user expectations. The tradeoff analysis helps one understand the strengths and weaknesses of a system. The ATAM method not only helps evaluate the current system architecture, but also helps with the design of architecture for a new system. This methodology helps designers to ask the right questions and solve critical issues early on in the project. Additionally, selecting the right degree of quality for a specific system fully utilizes the money spent by the customer, as the money spent in any one particular area of the system will be justified.

The ATAM process helps developers discover tradeoffs and sensitivity points

The tradeoff points are defined as the dependencies between attributes. The sensitivity points are the areas of the system that will be significantly impacted if system architecture is changed. The tradeoff points are the breeding ground for the sensitivity points, because when architecture changes the connections between different attributes changes as well.

One of the more obvious tradeoffs is the relationship between performance and security quality. Often the security quality is achieved by compromising performance; this is not a surprising statement as it’s general knowledge that making something secure requires a special effort. Even outside of the architectural context, securing a door in a house requires a purchase and installation of a lock – and that’s only the initial costs. The effort required to lock and unlock the door each time it’s open/closed is an additional cost/effort element. In this out of context example performance of the door can be increased by not installing a door lock. With no lock there is little security, as anyone can open the door with no trouble. The tradeoff points in this example are the presence of lock(s) and the speed at which a door may be opened (perhaps for security reasons it can only be opened at 1 foot per hour).

Key sensitive points are like the gauges that must be monitored by an architect each time a change to a software system is considered on an architectural level.

Do you evaluate your software architecture?

At the end of the day a systemic architecture evaluation method is up to the architect to decide. What matters is that an architect has a way to judge whether architecture is the right fit for a business problem at hand. Other evaluation methods exist and serve various purposes: SAAM, ALMA, FAAM, CBAM. Some even use this assessment form.

Post a comment if you evaluate software architecture. How do you do it?

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Boundaries between "Architecture", "Design", and "Implementation" formally defined

Insightful paper by Rick Kazman & Amnon Eden, presented at ICSE 2003, that defines the boundaries between "Architecture", "Design", and "Implementation" by formalizing the ‘Intension and the Locality criteria, which imply that the distinction between architecture, design, and implementation is qualitative and not merely quantitative.’

Basic understanding of formal notation (esp. Zed) is necessary for enriched reading experience.

Download the paper from SoftwareArchitectures.com or SEI.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Frank Lloyd Wright

Frank Lloyd Wright, one of the most famous American [building] architects of all time, worked on over 500 structures and left a few notes of wisdom for us to consider. While the comparison between software and building architecture breaks down pretty quickly, the quotes below apply to both disciplines.

1. A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.
2. All fine architectural values are human vales, else not valuable.
3. An architect's most useful tools are an eraser at the drafting board, and a wrecking bar at the site.
4. Every great architect is - necessarily - a great poet. He must be a great original interpreter of his time, his day, his age.
5. Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.
6. Get the habit of analysis - analysis will in time enable synthesis to become your habit of mind.
7. Less is only more where more is no good.
8. The architect must be a prophet... a prophet in the true sense of the term... if he can't see at least ten years ahead don't call him an architect.
9. The architect should strive continually to simplify; the ensemble of the rooms should then be carefully considered that comfort and utility may go hand in hand with beauty.
10. The truth is more important than the facts.
11. "Think simple" as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Static, Runtime, Physical

For the spring 2008 semester I function as a distance education instructor for the Principles of Software Architectures course offered by the School of Computer Science at the Carnegie Mellon University through the Institute for Software Research International. As I reviewed the course I fondly remembered the lectures by Prof. David Garlan and Tony Lattanze while pursuing my Masters in Software Engineering (IT) degree some years ago. At the same time I reflected on the architecture representation practices employed on some of the recent projects I’ve reviewed and sadly the state of affairs is looking pretty grim.

It is still common to see software architecture designs mix incongruent design elements together, such as combining message flow process with a class diagram. As a gentle reminder, architecture of a software system is represented through a number of views that describe some angle of a system. There are many different views that can be chosen by an architect to represent some aspect of the system (e.g. process view, deployment view, decomposition view, etc.). No matter what view an architect chooses to document some aspect of architecture it’s critical to understand that most views can be classified into static, runtime, and physical. It is absolutely critical to maintain conceptual integrity of a given view; otherwise you may be comparing apples to oranges. If this is new to you read a copy of Software Architecture in Practice, Second Edition, take this course from Carnegie Mellon, or take a class from the Software Engineering Institute.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Edward Hopper - Communicating the Essence

It’s the architect’s job to decide and communicate which quality attributes need to be emphasized in order to achieve the overarching mission of a solution. Similarly the iconic American artist Edward Hopper, in his paintings, captured the essence of a scene while abstracting the negligent elements of the situation.

In painting Haskell’s House you clearly see that the artist chose to omit the wires from the electrical poles. The busy harbor behind the house is not depicted in the painting: the core emphasis is on the house. Also notice how the sun rays draw your attention on the house and you can almost forget about the mundane details of trees, landscaping, and electrical poles. A software architect has a similar job: capture the big picture (e.g. security, environment constraints, composition of services), but note the critical solution qualities (e.g. usability, performance).

In the infamous painting, Nighthawks, Edward Hopper uses light and shadows to concentrate viewer’s attention on the situation in a dinner. Notice lack of pedestrians, cars, or any other artifacts that would detract from the developing situation inside of a dinner. The viewer may dully acknowledge the presence of outside, but all the attention is concentrated on what is happening on the inside. Similarly an application architect that works in a mature design environment simply needs to acknowledge the presence of certain assumptions, but concentrate his work on the essence of a solution.

The 1940 painting Gas shows a lonely attendant at a gas station. There are no cars fueling or on the road. The obvious, cars, is not commuicated.

If you ever have a chance to see a collection of Edward Hopper’s paintings do not miss that chance. A closer look at the paintings can be found here.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Software Architecture Conferences and Events

The Software Engineering Institute maintains a comprehensive list of "upcoming conferences, workshops, and calls for participation that explicitly include "software architecture" among their topics of interest." This is a good place to start if you're looking for an opportunity to share thoughts with like minded individuals outside of your immediate circle of software architecture contacts. Research each event with care, as different user communities look at architecture from a different lens.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Selecting COTS software under pressure (Forrester and Gartner)

This happens on many projects: everyone agrees that the core of a solution (e.g. workflow engine) will be purchased instead of built from scratch. This is an absolutely rational decision for most enterprise applications. The next question is which vendor to select.

The rational approach is to identify the core functional requirements and key quality attributes that the solution must exhibit. This is an absolute must; because without understanding what you need you will not be able to objectively judge your options. The criteria on which you should evaluate you COTS software candidates must be granular and quantifiable to the degree that makes sense. Each criteria element needs to be weighed against all other chosen consideration elements so that all weights add to a whole. E.g. In case of workflow COTS software the number of concurrent workflow processes that the solution must support has to be at least 400 and this criterion has a 15% importance in relation to other selection elements.

The next step is to conduct evaluation of the market space for available vendor solutions. A number of solutions will not meet the top selected criteria based on the marketing information from the vendor, but few will emerge as potential candidates. Since COTS software will be an integral part of the solution a targeted proof of concept should be implemented and results judged against the established criteria. The outcome of the test along with other evaluation criteria is used to make an objective and rational decision.

If a decision on the COTS software absolutely has to be made in a period of time that doesn’t allow a proof of concept, then you should buy the intelligence from a third party that has done COTS software evaluation for you. Both Gartner (Magic Quadrant) and Forrester (The Forrester Wave) provide analysis of various COTS products that fulfill a particular segment of business applications (e.g. BPM tools). Each vendor solution is evaluated against a wide range of criteria. These reports provide very valuable insight, but without objectively understanding the needs of the solution you’re architecting it’s not possible to fully utilize the insight provided by a third party.

In general a Gartner, Forrester, or another 3^rd party report should be used in any COTS software evaluation whether you’re pressed for time or not.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Globalization and Software Architecture

When I interview potential team members I always ask the question: “What is the impact of globalization on our company and on our clients?” This is not an easy question to answer and I’ve seen recent college grads and seasoned leaders alike cringe when they hear this.

The topic of the global economy is familiar to the IT folks. Many practicing architects are leveraging or at least familiar with the outsourcing software development models. But thinking beyond software architecture – what impact does globalization have on the business problem you’re trying to solve? Perhaps the problem you’re trying to solve is now nonexistent, or perhaps the complexity of the problem just increased by a factor of ten.

“What is the impact of globalization on software architecture?” This question I will try to answer in this blog in the near future.

With no clear answers this topic is a zero day problem for pessimists and a vibrant opportunity for optimists.

If you’re looking for a primer on the general topic of globalization I highly recommend reading "The World Is Flat" by Thomas Friedman.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Evaluating SOA using ATAM

This report, released by the SEI in September of 2007, is a very good example of applying the ATAM to evaluating an architectural style, such as SOA. You can find the report here.

The Abstract
"The emergence of service-oriented architecture (SOA) as an approach for integrating applications that expose services presents many new challenges to organizations resulting in significant risks to their business. Particularly important among those risks are failures to effectively address quality attribute requirements such as performance, availability, security, and modifiability. Because the risk and impact of SOA is distributed and pervasive across applications, it is critical to perform an architecture evaluation early in the software life cycle. This report contains technical information about SOA design considerations and tradeoffs that can help the architecture evaluator to identify and mitigate risks in a timely and effective manner. The report provides an overview of SOA, outlines key architecture approaches and their effect on quality attributes, establishes an organized collection of design-related questions that an architecture evaluator may use to analyze the ability of the architecture to meet quality requirements, and provides a brief sample evaluation."

Firebrand on duty: Constantin K.
www.softwarearchitectures.com

Neglected Aspects of Software Architecture

Todd Kaiser, a Chief Architect of Government Systems at Raytheon Intelligence & Information Systems, delivered an outstanding presentation at the 2007 SATURN workshop. The absolute beauty of the presentation is simplicity with which he delivered a very important message: some software architects ignore non-technical aspects of software architecture that results in “collateral damage.” In addition to concentrating on technical pillars of a solution: data, structure, and behavior, an architect must also actively weigh managerial, financial, and contractual aspects of software architecture. Your personal architecture world may be different, but Todd Kaiser’s presentation succinctly delivers the message that applies to most architects: architecture is more than just technology.

SATURN 2007 presentation on Neglected Aspects of Software Architecture.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Responsible Software Architecture

SoftwareArchitectures.com is propelling the concept of responsible software architecture. This concept is based on philosophy that every decision made by a software architect must be conscious and must be supported by a judicious decision making process that clearly demonstrates why the chosen design alternative was selected out of a range of other possibilities.

Every decision made by a software architect is made in some context at some snapshot of time. The context is defined through architect’s understanding of personal capabilities, requirements, constraints, financial resources, time, capability of the team, etc. The context changes over time, so it’s imperative to document the background against which a decision was made. When someone questions a design decision or suggests a better solution an architect must provide a scientific justification of his or her decision – without it architect’s credibility and the credibility of the solution may be compromised.

The concept of responsible software architecture is very powerful, but few architects live by it. Think about two or three most recent software architecture design documents that you reviewed. How many documents clearly explain the way key architectural decisions meet business drivers and why selected architectural approach is better than listed alternatives? Not every decision needs to be documented with an elaborative set of alternatives, but all key decisions need to be explained. Key decisions are architecturally significant choices that if changed have a profound impact on multiple quality attributes of a system.

A responsible software architect must sincerely believe that a business problem, and not technology, drives the solution. Technology may be the core vehicle for delivering the solution, but it’s not the driver – this is a paramount concept. Because technology is not the driver a responsible architect must be able to initially reason about a solution without technology specific terminology. The point here is that selection of a technology (platform, development tools, COTS software, etc.) is an architecturally significant decision that constraints the solution. An architect must be able to provide a judicious explanation as to why selected technology was chosen. Once that decision was made it’s only natural to think within the context of selected technology.

Some software architects have too much vested interest in a given technology so they only design solutions with that framework in mind. This clearly limits the range of solution alternatives, but it’s not as limiting as reusing the same architectural approach from project to project without justifying the reason for doing so. For example an architect who designed web based applications using MVC architectural style for the past four years may be inclined to use it on the next project even if a Front Controller style or an AJAX based pattern may be more appropriate. Similarly if an architect is used to a working with a process intense SDLC he or she may push for it without realizing that a new project requires agile JAD/RAD approach due to its research and development nature. The latter examples demonstrate the proverb: “When all you have is a hammer, then everything looks like a nail.” For an architect to be responsible he or she must question their decisions and make sure that appropriate audience is able to understand the reasoning behind the decisions.

SoftwareArchitectures.com is currently establishing a Center for Responsible Software Architecture. Join the discussion on responsible software architecture in a specially created forum. Each post will earn you a chance to win Evaluating Software Architectures: Methods and Case Studies book (through October 15 2007). Registration required to view and post.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Beyond Software Architecture - quick read

A dated (2004) yet applicable interview with Luke Hohmann, author of Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley, 2003).

Make this a quick read - Luke Hohmann provides interesting views on the human points of software architecture with respect to building enterprise software with agile methodologies in mind.

Some notable points:
- In the beginning architecture should be complete, but it’s OK for it to be immature. This is exactly what Fred Brook’s identified in his 1975 masterpiece “The Mythical Man-Month” (p. 94) when he identified the concept of conceptual integrity as the most important consideration in system design.
- Software architecture is a communication medium

Part 1, Part2, Part 3.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Microsoft's Reference Architecture

A software architect must have a comprehensive understanding of the technical environment in which a software solution will reside. Mature and usually large organizations usually have volumes of Enterprise Architecture (EA) that contain guidance and identification of the as-is state of the enterprise and the future evolution. The volumes of EA usually represent different levels of abstraction, but have a common theme centered on a business domain. Parts of the EA are meant to be used as reference architecture to guide a software architect in design of a solution so that it fits snuggly into the existing enterprise and so that a solution can evolve graciously.

Microsoft has developed a comprehensive reference architecture that for its Windows Server platform. It’s a “detailed reference architecture, tested and proven in labs, that yields valuable implementation guidance for meeting the requirements of an enterprise.” Even non-Windows enterprise architects will benefit from the recommendations in the Microsoft’s reference architecture documentation.

For each type of service reference architecture contains an introduction, a blueprint, a planning guide, a build guide, and an operations guide. Out of many services covered some notable are network devices, storage devices, firewall, certificate, backup, network, directory, file, data, web application, middleware, and messaging.

Microsoft’s reference architecture is well organized, easy to use, and very comprehensive for both Microsoft and non-Microsoft centric architects.

Home page | Comprehensive download MS Word documents in installer

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Startbucks The Way I See It #240

Sometimes there is more wisdom on the outside [of your Starbucks cup of coffee] than on the inside. From "The Way I See It" series #240 applies fluidly to software architecture:

If you can’t visualize it, don’t build it.
-- Constance Adams
Space architect and National Geographic Emerging Explorer.


Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Architecting With 3rd Party Components: "Trust, but verify"

A proverb: “Trust, but verify” should always resonate in software architect’s mind when a decision is made to use a component that the architect does not directly control. This component may be a COTS software piece or an enterprise library developed by someone else. This becomes especially important if that component is part of the project’s critical path (e.g. a communication infrastructure component).

For example, the enterprise may require every solution to use component Foo to obtain a security token. Or the enterprise may require component Bar to be invoked to pass through messages so that certain information can be collected for enterprise auditing purposes.

Unless you have previous experience architecting with that 3^rd party component take a safe path. Identify the elements of your solution that will rely on the 3^rd party component. Then thoroughly analyze the external component for each quality attribute requirement that is associated with the software architecture element that uses that component. If the documented performance, security, availability, and other quality attributes match the needs of your architecture proceed with caution.

Think about mitigation strategies (alternative implementation tactics) in case the 3^rd party component does not live up to the promised expectations. For example, can auditing functionality be done as a batch mode instead of real time? Can an alternative protocol be used for issuing security tokens?

As the implementation commences inspect the properties of the promised quality attributes with the intensity that is equal to the role that the 3^rd party component plays. If a 3^rd party component is part of the critical path of a project conduct intense quality attribute related tests prior to committing your architecture to it.

For designing with COTS software see this article.

Remember: “Trust, but verify”

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Revisiting the definition of software architecture

When was the last time you thought about the definition of a software architecture? It has been quite some time since I read the definitions posted on the SEI’s Community Software Architecture Definitions page. Some interesting definitions:

Eoin Woods (Software Architect, Investment Bank, London, UK): Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.

Adu Matthaeus (Systems Architect, Eikon, Centurion South Africa): A configurable skeleton of any kind of software beast on which you hang implementation specific muscle to make it live.

Jeff Winter (Software Engineer): … Architecture is necessarily a series of abstractions, depicting details relevant to one perspective while suppressing details relevant to other perspectives, and therefore expressed as a series of complimentary views. To say what those views are, you must embrace some ones method or make up your own.

Steve Wright (Consultant - Sr. Data Architect, Knowledge Management, Boston, MA): Architecture is the set of decisions that must be made at the enterprise level before specific applications are designed and built in order to provide conceptual integrity and sanity across the enterprise’s systems. Architecture includes a decomposition of the systems into separate orthogonal viewpoints along with the enforced rules that enable this clean decomposition and isolation of design viewpoints. This is done so functional (application requirements) and non-functional (system qualities) and other aspects of the application system may be defined and built by independent specialists in their specific field. An architecture not only divides the system, it also divides the roles and responsibilities of those who work with the system into separate organizational concerns and disciplines that are conceptually tractable and can be effectively managed.

Balakrishnan Thiruvadi (Technical Manager, HTC Global Services, Chennai, India): It is an art of defining, implementing, maintaining system and software environments that will assist and grow with business requirements.

Tim Simmons (Student, Southern Adventist University, Nashville TN USA): The architecture of a software system is its very essence. It is not merely a schematic showing interconnected components, but a description of those components and the way in which they interact. It is the foundation upon which the entire system is built.

Firebrand on duty: Constantin K.
www.SoftwareArchitectures.com

Software Architecture Discipline Splits

We dreamed about the software architecture discipline becoming a mature discipline similar to the way civil engineering has evolved over time. To a certain degree this has become true: a unique set of skills is not required to develop a basic accounting back-office suite or a large scale eCommerce site. Banal solutions are reproducible by anyone with basic software design knowledge. This is good, because seasoned architects are now reaching out to solve more challenging problems.

Up until now software architects were doing two jobs under the same title: mature software engineer and mature software designer. [Note that the word 'mature' is used over 'senior' since age does not equate to seniority or ability to design complex solutions.] The software architecture discipline will eventually split into those who concentrate on the art of the discipline and those who specialize in the science of the discipline. This is inevitable due to the ever-growing complexity of responsibilities a person with a software architect title.

All software architects need to have experience from the trenches (working on serious projects in the real world) doing programming, design, and experience in all other parts of the SDLC experience. However, the architects concentrating on the 'art' aspects of the discipline will find themselves spending more time understanding and eliciting the business problem and conceptualizing the solution. The architects concentrating on the 'science' aspects of the discipline will provide cross-check the concept and provide insight on concrete implementation options. The soft side of the architecture discipline will deal with the human aspects, while the hard side of the architecture will address technical aspects.

The need for further concentration by means of splitting architecture responsibilities into soft and hard sides comes from increased demand from the business users to develop solution that solve a business problem, as well as the need to deal with the continuously growing complexity of implementations and overflow of new technologies and tools.

Firebrand on duty: Constantin K.

Security for Software Architects

Security is about managing risk. No usable system is 100% secure – that’s a fact. Of course it is possible achieve 100% security by placing a system in a physically guarded bank vault and disabling all communication mechanisms. Based on how the society uses software systems it's clear that such approach is not suitable for most usable software systems. It’s not possible to defend against all vulnerabilities, not only because organizations don’t have the resources, but because new threats arise daily. It’s the architect’s job to work with the system stakeholders to seek the balance between risks and resources.

Read a new article on this topic on SoftwareArchitectures.com. It's written is for both seasoned and apprentice software architects in mind. Security has always been an important topic, but with rapid software evolution software architects are forced to pay more attention to this quality attribute. In not so distant past, before standardization of various protocols (e.g. TCP/IP, SMTP, etc.) most business systems were isolated and existed within the physical boundaries of proprietary communication infrastructure. At that time there was little, if any, electronic data exchange between organizations. The subject of security did not become prevalent until the need for interconnectivity and interoperability emerged and the cost of security breach became a real cost to business.

Firebrand Architect on duty: CK

Control Your Engine!

Imagine you’re building a car. You get car parts, including an engine, from various vendors [think COTS software] and different people help you put it together along the way [think contractors & subject matter experts across divisions]. You’re making progress – you have attached the wheels and can push the car through the product line [dev / test]. Now you’re reached the end of the product line. It’s time to start the engine and drive [pilot stage]. The engine turns but doesn’t start. After troubleshooting and double checking your work you find out that the engine [think messaging infrastructure] doesn’t work. The fuel tank is full [messages are sent from originator], the fuel line to the engine is full [message path is traceable], but the engine won’t process the fuel. When you ask for help from the engine integrators they blame the fuel line.

The engine is the mechanism that makes a car move in a similar way that a messaging platform makes software components work together.

The point of the analogy is to remind architects that in the environments where they are constrained by organization’s enterprise architecture the communication patterns and related infrastructure that glues their application may already be predefined. No matter how good the infrastructure products may be, blindly assuming that the people operating the infrastructure are able to configure it for your needs is a recipe for disaster. This is especially true for quality attributes of a system that require high volume of transactions.

In environments where you cannot control the communication infrastructure always design with a backup in mind.

Firebrand Architect on duty: CK

Business Improvement Through Better Software Architecture

In the 10^th edition of The Architecture Journal, published by Microsoft, a son & father pair have done an outstanding job describing architect roles in business software development. It’s not very often that you come across such a well written, eloquent, yet terse piece of writing that energetically captures the responsibilities of architect roles and the relationships between those roles.

The authors, Sten & Per Sundblad, state in the opening paragraph that “business software exists for one reason only: to support the business and its activities … there is no other reason for business software.” This is the premise of their philosophy and a fact that software architects often forget. Countless articles have been written over the past five years on lack of alignment between IT and business. Few of those articles presented the issues and solutions with proper level of abstraction that made reading this article equivalent to reading a really book that you don’t want to end.

The article is authors’ perspective and by no means a standard, but it’s a good use of your time and deserves placement in the Essential Selection.

Firebrand Architect on duty: CK

Asking for help - a mature decision

A software architect is in charge of the overall technical solution – there is no question about that. But a good software architect also knows his limits and requests assistance from subject matter experts on the issues outside of his or her knowledge base. Technical skills are only 49% of software architect’s skill set.

For example, a software architect with experience in web portal development is assigned to lead a project for a web based case management system. If similar technology and the same web based paradigm are used on the new project this is a reasonable request on behalf of the business management.

After studying case system requirements and after examining the quality attributes an architect sees that the system will require a highly sophisticated authorization system in order to ensure that the right users get access to the right parts of a case at the right time. If complex resource authorization is not architect’s technical strength, then a subject matter expert must be brought on board for consultation. This is not an insult to architect’s competency or ability to perform her job; it’s a mature decision that will improve the odds of designing the right functionality that serves users’ needs.

There are cases when financial constraints prohibit acquisition of external subject matter experts. Then it’s up to architect to make the best of the situation, but such decision should be documented as risk. It’s a well known fact that it’s not possible to retrofit security into a system without breaking system architecture.

Firebrand Architect on duty: CK

Effective Presentations by Software Architects

In an earlier post the topic of clear, concise, and terse writing was presented. This post raises the importance of effective architecture presentations. It’s critical for every architect to be able to create and deliver effective presentations in an amount of time allocated. The following tips, derived from experience, should be kept in mind. It is assumed you’ll be using a Power Point or similar software.

1. Mind your audience. It’s imperative to set the tone and presentation content based on the audience and audience’s expectations. If someone requests a presentation on the architecture of a system find out what they want to get out from the presentation. This will make the process of creating the presentation easier and your results will be measurable.
2. Mind your time. If you’re allowed 30 minutes for presentation you will only get 30 minutes. This is especially true with angel investors, venture capitalists, executives, and anybody who simply values their time. Extenuating circumstances aside – running out of time is a result of poor preparation.
3. Preparation is essential. Throwing some diagrams together and trying to wing it will result in poor quality. The presentation must have a flow that tells a story that your audience cares about. Prepare a handout outlining the key aspects of your presentation, but only distribute it when you start speaking.
4. Be professional. Your presentation slides must be in a consistent format. Font, positioning, color scheme must be uniform.
5. Practice. Most people fear public speaking. Those who don’t are unique or liars. When you hear yourself talk aloud while standing you’ll feel the areas of the presentation that do not transition well. Practice presenting in front of an audience even if it’s just one person who doesn’t know anything about software architectures. Practice will logarithmically build up your confidence unless you don’t know what you’re talking about.
6. Know your subject matter. The audience will be able to tell if you don’t know what you’re talking about – just by seeing your gestures, tone, and logic. Anticipate tough “why” questions and be able to respond intelligently. After all an architect must always explain why a give decision was made or not made.
7. Backup slides. Include backup slides at the end of your presentation if audience wants more detail on some part of a system presented earlier. Backup slides don’t need to be polished.

Remember that as a software architect you’re the chief spokesperson for a software system.

- Firebrand Architect on duty: CK

Architects need to improve their written communication skills

Effective written communication skills are essential for every software architect. Expressing your ideas clearly, tersely, and effectively is paramount. If your audience does not fully understands your vision or design, then you’ll have to build (and probably fund) the system yourself. It is your responsibility, as the architect, to ensure that your readers understand your ideas.

Written communication is important, because that’s the only effective way to communicate with a large number of people who may be geographically distributed across the world in different time zones. A single software architecture design package is often the source of reference for hundreds of people on a large scale system or a system of systems.

The international software engineering community recognizes English language is the standard language for cross cultural communication. Therefore it is paramount for any software architect to improve their skill set of the written English. Improving written English is probably even more important than improving oral English.

There might be many guidebooks for improving your writing, but my colleague and scholar of the English language recommended only one book: “The Elements of Style” by William Strunk. The book has been in print for a few decades. It is available in the original edition, the illustrated hard cover edition (my copy), and the fourth edition. The content is about the same across all of the editions. This book is a definitive reference guide for an everyday writer. The book has no prerequisites and can (and should) be used by every technical person. After using this book you will notice that your ideas are shaped more clearly and your sentences are easier to understand. This book belongs on your technical books bookshelf.

Beyond technolgoy in technical books - joy for architects

The winds are changing – the software engineering mainstream practitioners are finally starting to value the importance of the human aspects of software engineering. And that’s only good news for software and solution architects.

If you’ve been reading some of the newer technical literature, such as the Pro [Microsoft] BizTalk 2006 book, you would have noticed one paramount shift in the book’s introduction part. First the authors provide the core overview of the BizTalk architecture, as expected, but then spend the next chapter going over various human and organizational aspects of running a project.

This is important. This shows a conscious effort on behalf of the authors to convince the reader that establishing a technical and management structure is essential to the success of the project. The book provides brief guidance for setting up communication chain of command, provides an example of a rudimentary build and deployment process, and emphasizes on the importance of organization and team work.

Most books a specific technology only concentrate on technology and often neglect the human aspects of software architecture. The Pro BizTalk 2006 does a fine job of emphasizing, if not requiring, that software engineering practitioners follow best practices when utilizing BizTalk 2006.

- Firebrand Architect on duty: CK

The cost of politics on software development

My gut feeling is that organizational politics introduce a 25% overhead on all software development projects. I strongly feel that a formula can be devised to determine the cost of politics on software development. As a matter of fact when I pondered pursuing a Ph.D. in software engineering I thought this may be a worthwhile topic to explore.

The reason this subject matter is brought up in this blog is because politics are unspoken constraints on a project.

The software architecture practitioners are finally maturing to a point where system’s quality attributes are measured in a meaningful way. For example, to express performance requirements of a certain aspect of a system an architect would create a scenario that may sound something like this: “8500 users stochastically add one item per minute to their shopping cart while the system operates in the ‘holiday shopping mode’ and the requests are processed with an average latency of 3 seconds.” A series of such scenarios provide a working reference for an architect to aid him in design a system to meet these quantifiable requirements. But how to measure the politics quality attribute?

Finding a way to measure politics in some useful and meaningful way is important, because politics present design related constraints and risks that must be mitigated. In my recent architecture analysis task I noticed that a cluster of database servers had to be two thousand miles apart from the web and application servers. When I inquired about the reasoning I was tacitly told that the two different bosses from two different datacenters wanted a stake in a high visibility project. I was assured, however, that a “very fast backbone” will provide sufficient latency between the locations.

The first step to tackling this problem is to define what one means by politics and in what units can this property be measured. Because politics are unspoken in most organizations the architect would have to decide how to represent this constraint and mitigation strategies on paper. Or can this be done on paper? Or is this something that an architect should document privately? If so, who else should be aware of this information?

Your thoughts are welcome.

- Firebrand Architect on duty: CK

Listen. Observe. Think. Speak. When passion limits your potential.

This post is a reflection on the past behavior that landed this firebrand architect into a counterproductive situation and, temporally, put him in a penalty box. Let this be a warning to others.

Before joining this project on a full time basis I was invited to spend time evaluating the existing architecture and make recommendations before the development phase would commence. During the architecture review & analysis process I have identified a number of risks, in light of project constraints, including application’s laborious authentication and authorization requirements. To address this risk I proposed integration of a well known .NET compatible COTS software access control and authentication component.

Luckily the organization’s Enterprise Architecture (EA) has already authorized utilization of such component, and even already possessed an enterprise license for its use.

A large (eighteen person) meeting was called to discuss future placement of the solution in development, test, and production environments. Heads of various environments as well as select technical staff were present. Utilization of various EA resources, including the access control component, was on the agenda.

During the meeting the technical lead representing the component stated that only the authentication part of the component is usable within the enterprise. Naturally, I questioned why the wealth of authorization functionality is not available for the project’s use. The technical lead didn’t have a good answer and responded by saying that nobody is using it. I passionately pushed further explaining how much this project would benefit from such functionality, I went through the key features, and even volunteered to assist the tech lead with configuring the component to make the authorization functionality work.

After the meeting the product’s chief architect and I reflected on the stubbornness of the technical lead to even consider looking into utilization of the access control functionality of the component. We both felt that the technical lead took the stance of “if it’s not broken don’t touch it” and was afraid to look into our request.

Soon after the meeting the program manager requested that this firebrand architect not be taken to other “high level” meetings. It turns out that what I thought was a passionate appeal to utilize desired functionality was perceived as arrogance.

Reflecting back on this event, quite some time later, I see the obvious mistake. It’s not that the action of the appeal for desired functionality that was wrong; it’s the presentation and timing that was off. After receiving a mediocre answer from the technical lead I should have documented my case and presented it offline to the program manager who was also present at the meeting. Since this was my first meeting with these high level representatives I had no sense of the existing political situation and pre-existing issues. A smarter move would have been to listen, observe, think, and then speak – offline. This was not the first time I participated in such a high visibility meeting, but this was the first time I ran into a group of highly sensitive individuals.

Three months later, after I have regained full confidence of the program manager, I was placed into a leadership role that required me to participate in similar high visibility meetings.

The moral of the story is to listen, observe, think, and understand the environment and the political situation first; and only then to speak.

- Firebrand Architect on duty: CK

Information sharing / architecture documentation sharing

In a survey taken by SoftwareArchitectures.com in the spring of 2006 over 65% of the visitors were most interested in seeing practical examples of software architectures. The architecture of the real world enterprise grade software systems is proprietary as it represents the competitive advantage of an organization. Therefore it is difficult to obtain software architecture documents of such caliber, which consequently hinders information sharing between software architecture professionals.

But it is still possible to share the essence of software / system architecture without compromising organizational secrets. To achieve this, first, complete anonymity of the submitter must be assured. Second, the proprietary information must be rewritten or removed (e.g. IP addresses, company name, product name, interface systems, etc.). Third, the business problem solved by a system must be generalized. Fourth, implementation specific information must be removed to a level that does not give away owner’s identity.

Who will invest their free time into doing this? Only those who want to obtain feedback on the architecture from the greater software architecture community. Caveat: constructive feedback is not likely as long as the architect and the reviewers are not utilizing the same architectural paradigm while discussing the document.

SoftwareArchitectures.com has a library of usable, complete, and well-documented software architecture design documents available for free. See the Case Studies link on the main page.

- Firebrand Architect on duty: JP