IF YOU BUILD IT

... Will they Come?

April 2006

I read Alik Levin's "I do want to write secure code, where do I start?..." post a few days ago. What caught my eye was the statement:

"To me, application security is not different from other application feature--really it is not."

Well, I think this statement is wrong. Here's why.

On one hand, security doesn’t add direct value to the users of the system. Security doesn't alter the way the application behaves--and if it does it is for the worse. For example, usability-wise it is a nuisance to have to key in a password before you can start being productive. Moreover, adding encryption/decryption makes it harder to achieve performance requirements.

On the other hand, adding security is not like adding a support for Gold and VIP statuses to the Customer Service. It isn't really isolated to a specific area of the application; rather you need to pay attention to it all over the application and in several different levels.

Nevertheless security is very important--and while the lack of security will not alter the solution functionality, it will have an impact on the quality of the solution. This characteristic of security makes it a quality attribute of the system and thus an architectural element.

Posted by Arnon Rotem-Gal-Oz at 01:26 PM  Permalink |

Software architecture is technology agnostic. For example, if you say your architecture uses message communication, it really doesn't matter if the technology mapping would be a SoniqMQ JMS or Microsoft's .NET with MSMQ or a C++ API to Tibco Rendezvous.

Fine, end of post! .... But wait. (please excuse me while I murder Shakespeare)...

To (technology) map or not to map. That is the question. Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous fortune...to map, to map perchance to mis-map -ay there's the rub.

Indeed, all is well-until you make a technology choice that is misaligned with the architecture direction you took results in viscosity that makes it hard for the developers to do the right thing--the end result of that would be either you have the developers sweating to make things work or they will just cut corners and circumvent the architecture.

For example, I was working on a system where we decided on an SOA. We were trying to evaluate different options for a service bus when management decided we should use an existing asset--which happened to be a distributed-objects framework. We tried to explain that there's a technology mismatch, but it wasn't until four iterations later (4 months) of suffering from the ill-effects of this choice that we managed to demonstrate that new requirements for survivability and availability of the system were extremely complicated and costly to implement using that technology. Finally we were allowed to replace it.

My advice is that once you decide on an architectural direction--take a look at your technology options and vice versa; that is, take a look back at the architecture and evaluate what are the implications of your choices.

Posted by Arnon Rotem-Gal-Oz at 08:51 AM  Permalink |

Test Driven Development (TDD) is, in a nutshell, writing a unit test up front--making it fail, making it work , refactor, and repeat until the product is finished. (If this is new to you, read more at testdriven.com )

So with TDD you get a bunch of unit tests that are also proven as regression tests. That's pretty cool.

TDD also lets you work in small increments while maintaining the working code. That's even cooler.

And lastly TDD has a very good influence on design:

1. It encourage loose-coupling. When you want make something testable you want to remove the dependencies it has so you can test it by itself.
2. It makes you think about the interface of the unit under test--how is the interface going to look?
3. It makes you think about how the unit under test would be used--for example, the behavior of what you are writing (or designing).

Sounds great to me. I think TDD is a great way to do the detailed design. You specify the results (interface + behavior), then implement that design. One thing I don't buy though is that TDD alone will produce an "emergent design" for the whole system. The way I see it is that you have to do some design up-front (assuming your system is not a trivial one) since TDD, being a coding technique, keeps you working at sea-level.

There's also a fundamental matter of scale--it might be possible in theory to start that 100 man-year project as a single object, then refactor it in baby-steps until you'd get the perfect system. I believe that if you don't work at a higher level of abstraction (vs. code), you will not be able to partition the system in a reasonable time. This was true when we moved from assembly code to higher level languages which enabled us to write much more complex software--and it is true today as we need to answer the ever-changing requirements of modern enterprises.

To sum up, TDD is good for testing and it is a good design methodology for the detailed design level. It can be used to drive the overall design on smaller project--but on larger systems we need additional methods and tools to cope with the overall design and architecture.

Posted by Arnon Rotem-Gal-Oz at 05:26 PM  Permalink |

If you are agile and agility is about getting closer to code, then you--the architect--should be coding with the development team, right? And if your not, are you simply sitting in an ivory tower and without any real knowledge about the project? Or as Michael Stal puts it in his blog on the architect's role:

Implementation Expertise: Architect always implements. That basically means, "eat your own dog food". An architect must product designs that can be implementable software architecture. And she or he must be able to refactor when necessary. Thus, an architect needs to participate in implementing and unit-testing....

I don't subscribe to this point of view. I believe that if architects take part as developers in the team, they will get bogged down with the gory details of detailed design and implementation. They will have trouble (deadlines, deadlines) lifting their head enough to see the big picture or pay attention to the problems in other areas of the developed software.

I do think that the architect should be part of the development team, but in the role of architect--act as a mentor, lead the architecture design, contribute (or at least review) designs, and participate in (selected) code reviews.

I also strongly agree with Simon Brown's view that the architects should posses coding skills as well as understand and have a good handle on technology.

Architects should be able to--and often needs to--create prototypes both to prove their point as well as a way to communicate it.

On small projects, it might be possible for a person to take two roles; for instance, work under the architect role as well as code in a developer role. However, in such cases it would probably be more beneficial for the company to get the architect to work on more projects and share their expertise, rather than limiting their contribution to a single project.

Posted by Arnon Rotem-Gal-Oz at 04:24 PM  Permalink |

Is there such a thing as "Agile Architect"? Isn't agility all about not planning ahead, and just writing code and refactoring?

Let's start off by looking at the Agile Manifesto :

"Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more"

Agile zealots tend to miss this point, but it is should be noted that planning, tools, processes, documentation, and the like are not banned--they are just not favored vs. their counter options.

So Agile Architects should be part of the development team, working closely with developers and customers. Agile Architects will strive to have any assumptions they make validated in code as quickly as possible. Agile Architects should strive to have flexibility (the ability to respond to changes) as a top-ranked quality attribute of the system. Agile Architecture is communicated by code examples and proof of concepts, whiteboards and meetings, rather than by formal documents. Agile Architecture documents and models should be "barely good enough" (see Scott Ambler's essay).

If you want to read more about Agile Architecture, have a look at  Scott Ambler's site mentioned above or Andrew Johnston's site.
 
One interesting/controversial point is: Should architects code? I'll talk about my opinion on the next post.

Posted by Arnon Rotem-Gal-Oz at 12:25 AM  Permalink |

Looking the software architecture definitions mentioned in the previous post, we can see there are characteristics that are more prevalent than others:

• Architecture is early. It represents--well at least, it should represent--the set of earliest design decisions which are both hardest to change and most critical to get right.
• Architecture is an attribute of a system, whether or not its design was international. Every system has an architecture.
• Achitecture is about breaking a system into components and setting boundaries. It doesn't describe all the components--it usually deals with the major components of the solution. Also, it doesn't describe the complete characteristics of components--it mainly deals with their interfaces or other aspects that has to do with their interactions.
• Architecture is about the relationships and interactions of components. Again we are interested in the behaviors of the component as it can be discerned from other components interacting with it.
• Architecture explains the rationale behind the choices (vs. the choices not made). It is important to understand the reasoning as well as the implications of the decisions made in the architecture since their impact on the project is large. Also it can be beneficial to understand what alternatives where weighted and abandoned (for future reference, when/if things needs to be reconsidered, and for anyone new to the project that needs to understand the situation).
• There isn't a single structure that is the architecture--there's a need to look at the architecture from different directions or viewpoints to fully understand it.

It is also important to note the following two points:

• Architecture is a type of design (but not all design is architecture).
• Architecture is the first design artifact where a system's quality attributes are addressed. Where quality attributes (some call them "non-functional requirements" or "ilities") are requirements for the system as a whole ( e.g., security, performance, availability, flexibility, etc.)

To sum things up, here is my definition for software architecture:

Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attribute requirements. The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size).

If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders.

Posted by Arnon Rotem-Gal-Oz at 03:58 PM  Permalink |

I was recently involved in an effort by Microsoft Israel to come up with definitions for "software architecture" that fit the Israeli market (that is, in Hebrew). I was reflecting on this effort when suddenly it hit me: Everybody--and I do mean everybody--is trying to define software architecture. Here are few examples :

IEEE 1471-2000: Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. (Almost 30 committee members, including Philippe Kruchten, came up with this definition.)

In "Who Needs an Architect" Martin Fowler quotes Ralph Johnston as saying "Architecture is the decisions that you wish you could get right early in a project."

Len Bass says "the architectural design of a system can be described from (at least) three perspectives -- functional partitioning of its domain of interest, its structure, and the allocation of domain function to that structure."

Microsoft's Michael Platt recently defined architecture as: "Architecture is the use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting."

Charlie Alfred from Foliage Software Systems defines architecture as:
Software architecture consists of the rules and principles for how a system is decomposed into its component parts, the rationale for how responsibilities are allocated among those parts, and the policies and mechanisms that coordinate the interactions between those parts as they collaborate to fulfill the purpose of the system. (http://www.sei.cmu.edu/architecture/definitions.html).

Software architecture is at once the partitioning of a system into its significant elements, and the organization and integration of those elements into a cohesive whole. (IASA taxonomy workgroup)

SoftwareArchitectures.com defines it as: "Software Architecture is a set of abstract views that define a system in terms of 'elements' and the plumbing that allows for interaction between the 'elements'."

You can find literarily dozens of more definitions at this Wiki and at the Software Engineering Institute.

Oh, and there's my all-time favorite (presumably by Kent Beck): What is Software architecture? It is what software architects do.

Why are there so many definitions? What are the common characteristics of all these definitions? On my next post, I'll clear some of the fog and maybe even come up with a definition of my own. After all, if everybody is so infatuated with defining what software architecture is, why shouldn't I?

* The title is inspired by Robert C. Martin's Uncle Bob presentation at SDWest 2006.

Posted by Arnon Rotem-Gal-Oz at 03:03 AM  Permalink |

Hello, my name is Arnon Rotem-Gal-Oz and I am a software architect (I guess now it is your turn to chime in with "we love you Arnon" but I digress). Jon Erickson offered me the opportunity to write your daily blog on Architecture & Design -- and apparently I agreed, so here we are.

Software Architecture is a good subject to explore. On one hand, everybody is talking about it, and on the other hardly anyone really understands what it is. This is very good for me, as I can write just about anything related to software and claim it falls under the software architecture umbrella. Expect to see here my musings on software architecture and software design in general, links and commentary on what others have to say, and architecture related news. As we are nearing the end of this "Hello World" post I'll just add that I hope you would find this blog interesting and that I'd be happy to hear any comments you may have on any of my posts.

P.S.

If you are wondering who the hell is this guy -- you can take a look at my bio here.

Posted by Arnon Rotem-Gal-Oz at 06:40 AM  Permalink |