Owning the Architecture

One of the main principles in Software architecture is the fact that there is always an architecture. That is, there is no system made without an architecture in place. Good or bad, the architecture is, conceptually, the system structure, the organization of components, their relations and the relations they have with the system’s outer world. So, you cannot have a system without it.

The problem, discussions and disagreements come when we address the architecture actual handling. There we may find the position of letting the architecture “emerge” from the code written. Architect’s are sometimes decidedly marked for extinction, since they are not needed for development, simply because they do not “code“ but perform a Big Design Up Front that is useless at the end of the day (that is what that position holds as true, I disagree of course). Other positions often refer to architects as facilitators for high level design and decision takers regarding global and important issues. Yet, to others, architects are just highly experienced developers that should be helping coding, another level just above the senior developer.

The position I now describe here is the one I heartily believe is the one all architects should adopt. (Just because it is the natural one for handling the architecture.)

First, let’s see what’s been done so far…

How do you deal with the system’s architecture?Well, you can:

1.  Develop, code and later on see what was created.
2.  Define it (design) and then try to create it by development.
3.  Forget about it. Focus on code.

As you can see, architecture will be always there, but it will grow wild in all three cases. Yes, case 2 also has problems since almost 100% of the time the resulting architecture is different (sometimes substantially different) than the one defined at the beginning. Common sense dictates that we should at least foresee the architecture from the beginning and start building it with code, keeping an eye on what that code is actually producing.

Now, no matter what you do, you end up defining an architecture. Either by planning, by designing, or by directly coding it. At the end, the architecture is defined by someone. The question is then who? (architects? Developers? The client?) And then How?  (coding? Designing? Deciding?). Common sense dictates again that all those roles are involved in the definition and creation. That means there should be a coordination, and a high end control of what is going on (not dictating, but controlling). That role is, of course, the one of the architect.

How does an architect control the architecture definition?Well, we have several stereotypes applied to architects, that we can recall:

1. The documenter. Architects are seen as document generators, that are happy writing designs and other documents nobody reads.
    
2. The technical Project Manager. Here the architect is the one managing the project at the technical levels. A technical lead. Sometimes a technical director. Some others a technical puppeteer that holds the developers strings.
    
3. The Ancient, Know-It-All. This seems to believe that years will create a good architect, with unsurpassed knowledge. Many time this architect is seen in a Ivory tower, and some others it just holds the answer to all questions.

None of the above stereotypes really deal with the architecture control. Documentation may be an important tool to keep updated information of what the architecture looks like in a precise moment in time. There should be enough coordination and direction capabilities in the architect to manage the building process. And of course, there should be enough experience to make the correct decisions, coach, mentor and provide advice to coders and designers. Still, documents are not the final goal, nor the architect dictates directly what is to be done, nor he knows all and should not be at all difficult to approach.

So, we can say the Architect Owns the architecture. Owning means basically being responsible of:

1. Knowing what the architecture is, looks like, in a moment in time.
    
2. Adjusting the principles, decisions and rationale based on the feedback got from the development process (this includes the information that actual coding returns, plus stakeholder feedback).
    
3. Rectifying actual coding and design if that breaks the rationale of the defined architecture.
    
4. Make everybody included in the development process (that also includes stakeholders), participating on the adjustments and the architecture visualization.

It is clear now that the architect’s role goes far beyond that just imagine a proposed architecture at the first phase of the development process. It is responsible for the real architecture, the one built, at each step of the cycle. For that he will need:

1. Visualization of the real architecture. It is out of the scope of this post to discuss how to do that, but one process I should mention is the “In Deep, Vertical Peer Review” that involves all three levels of review (strategy, tactical and operational) in all the phases, instead of just one review per phase.
    
2. Rationale and goal validation. This process is very important, where we can validate the goals are still being achieved even if there are changes in any of the levels. For that, rationale is extremely important.
    
3.  A trade-off process. Of course, it is impossible to always achieve everything. There should be a trade-off process that evaluates the options and resolves for the one that keeps the goals as unchanged as possible, and results in the least cost. This of course involves all stakeholders.
    
4.  A cross refactoring process/redesign. All adjustments will change things. Refactoring is a way to improve things without changing actual behavior. The redesign may change behavior. The idea of the process is to try keeping the changes at the lowest level. That is, try first to adjust only code, without changing design nor strategic/architectural decisions. Then go up. The strongest change will require the architecture redefinition, with possibly the highest cost.

All this applies to all phases, including the quality assuring, deployment and acceptance.
How to do all that in different contexts and projects require a whole book. So far let’s simply summarize that:

1. Architect deals with many tasks, including but not restricted to documenting, managing and deciding.
    
2. The architect’s responsibility is to get an architecture done (meaning, built) satisfying the stakeholders goals. This requires continuous verification of goal and business value achievement.
    
3. Performing all that goes far beyond just coding.

Conclusion: Owning the architecture means being responsible of its construction, taking care of all the complex processing that development requires.

YAMTCARO and the Service apology

I just wrote an answer in TSS that I thought I could share here too. The basic idea everyone has about services is that they are to distribute logic, make remote calls, have loose coupling interfaces, and are resusable. And nothing is working as it is advertised. I will play the defendant part here.

“I see a repeating idea about SOA, services in particular, that doesn’t fit in what I have learned from my childhood as an architect. I will explain myself.

I recall the old Object oriented days when all the fuzz was about reusability. The idea was clear: separate the code into coherent and functional complete things. Then a problem was found: the interface. You could not reuse the thing because of the interface not being suitable, or requiring things not in the new problem domain.

Then a service came. It was the idea of having a business functionality (not an interface, not an object) able to accept messages and offer a business value. It has no reusability concept, the fuzz was actually about replacing fixed interfaces with a simple port. And somebody said: Let’s implement it with SOAP. And SOAP was Simple Object Access Protocol, an RPC oriented wrapping protocol used to access distributed objects. Wow. Wait a minute. Something is not working here. I know objects were supposed to accept messages. Nobody uses that. But a service is not an object. A service has no methods or parameters. Definitively, it has no response. There is no interface per se, just a port where you deliver your message.

Now, the message is not SOAP. SOAP is a wrapper. The real thing is in the body.

Once the service has read from the port the message content, it will now know what to do. And it may decide to send another message. As simple as that. But as difficult to grasp for an object programmer, that it was reduced to a YAMTCARO (Yet another method to call a remote object).

NOw, can somebody tell me why a service needs a method name to be called? SOAP had stubs in the client, to simulate the remote object as local. Services are not object, stubs have no place here. Makes no sense. You need a port object to stream your message. Simple.

Finally, since a service is just a port, and the service semantics (which are not technically describable) is hidden behind the service cloud. You can create a versioning system underneath the cloud, so old messages can still be accepted and new messages, that represent new business needs, be processed as required. Service cloud still as white as before. It may have a new port, but old ports may be still there.

Enterprise architects? Their job is to have one eye in the problem space, and the other in the solution space. They will work with business people to design services scope (business driven), and work with designers to technically create the structure of the cloud.

Hope this helps to understand why I say all that I say.”

William Martinez Pomares