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.

An Evolving Architecture?

Written by: William Martinez Pomares
Published on March 1st, 2009 @ 04:42:42 pm , using 619 words


Neal Ford from ThoughtWorks, recently wrote an article that is the first of a series related to architecturing and design called Evolutionary Architecture and Emergent Design. The first article is a revisit to the architecture and design concepts. In it, Neal describes the evolutionary architecture with these lines:

However, just because you can't allow architecture to emerge doesn't mean that it can't evolve. If you have created a flexible architecture and taken care not to create an irreversible decision, you can allow it to evolve over time as new concerns appear.

Now, I wrote a comment on TSS where I think the "Evolutionary" name may be applicable to the architecture concept I have:

In several discussions I had had, the idea of an architecture is repeatedly presented as a bunch of paper with fixed ideas that will not come true after all. I argue that should not be true.
Granted, a bunch of paper may define the "architecture to be", but the architecture is not ideas but the actual structure of working software at the end. So, Architects must define the final goal not as an stone written truth, but as an ideal outcome which will be supported by principles and guidelines to succeed. Those guidelines should show the path of adjustments to the ideas depending on the construction evolution. And all that is aimed to solve the stakeholders concerns.
In that line, and architecture is what you get at the end, and you set your goals and guides to drive the solution at the beginning, and make your decisions not as late as you could but as soon as they are in the best moment to be taken. (Yes, it is not the same). Under that idea, the architecture is something alive, that will change over time while it is being developed. It "evolves", and that is what I like about the article.

Still, something feels not quite right with this. And that is the idea of thinking we have an architecture from the beginning to evolve. Yes, what we have is a goal with a nice idea of what the architecture will be, but no real architecture (remember the real architecture is what you have once the project is done).

Now, let's clarify this further:

Evolution: the process of removing and adding features or improvements so the new product is better. The natural evolution may be by chance, but the induced evolution is pre-defined.

Evolution Rules:Evolution always follow a predefined set of rules. For architecture, these are the principles and guidelines defined at the beginning of the project.

Designed Architecture: The description of the Architecture-to-be that solves the stakeholder concerns.

Real Architecture: The one you have in every system, even if it is not documented. Of course, you need to finish the system first.

Using the above terms, you can have a set of concerns, the you design an architecture and a set of principles and guidelines to construct it. Those principles should allow for modifications based on a retrospective analysis of the results so far, at each step of construction. Once construction is over, you have the real architecture.

The thing that evolves, is the actual architecture design, the real architecture is emerging. Unless you construct whatever you think of first and then start changing all that is not working to improve. There you can have not one, but several architectures, one is the evolution result from the previous one.

Finally, you can have, as Neal mentions, an architecture designed to evolve (with flexibility included), which is different of what we are talking here. That would be an evolving system that has an architecture that allows it. Tricky!

REST and the Wagging The Dog Syndrome.

Written by: William Martinez Pomares
Published on April 9th, 2009 @ 11:06:45 pm , using 559 words

Commenting on Tim Bray’s blog post about the use of Post for REST, I came to a discussion about actually how much RESTFull is an API, and more specifically if it should be RESTFull at all.
You see, many people is trying to get their APIs into the REST world, and some people like Dilip Krishnan believe the reason is to gain "simplicity, discoverability and serendipitous reuse of the solution". Still, as I read through all the comments on how to "imagine" the app so it fits REST, I feel a greater sense of something not right about it.
When creating a solution, you may want to analyze first the functional requirements, and then the quality properties. The ones noted by Dilip are great, but I’m not sure all apps that hit the web every day need to accomplish them. Furthermore, REST is not the only way of getting those attributes! Let’s explain a little what this famous style is so you can understand what I’m saying.
The REpresentational State Transfer style was born as an architectural style to represent/improve the modern web implementation, as Roy Fielding explains in his dissertation. So, REST is an architectural style, and that means it has a set of constrains that the app needs to adopt to obtain the benefits. But that architectural style is not built from scratch. It is built by composing several other well known styles like Client-Cache-Stateless-Server, Layered-Client-Server or Code-On-Demand. Any of those can be used separately and all their pros and cons will be cast upon the solution.
Now, this is a special case where an implementation is taken as a base to develop an architectural style that improves it. Usually, you have a solution to build with a set of requirements, and you look for an style that better fit into the problem. But once you start changing the problem just to adjust to an architectural style, you are actually “Wagging the Dog” there. And it seems to be a contagious syndrome.
So, what does it need to have an APP to be worthy enough to use the style? Well, first

• - the semantics should be the ones of the style.
• - Next, the app should try to solve a similar issue the style is solving, and third,
• - the app’s quality attributes should be the ones the style is promoting.

If some of the three is not true for your app, and you still want to use the style, I may guess you are trying to get the buzzword title instead of the real benefits.
One little clarification at this point: The web is one implementation that follows the style, it is NOT REST itself. What do I mean by that? Creating an app that runs on the web doesn’t make it RESTFull. Using HTTP for your API won’t make it either (I wanted to clarify it since all comments are about HTTP and its semantics and it seems everybody confuses the implementation with the style). You need to read the dissertation to learn all the constrains, but even more important, to learn if the style is for you or not. You may learn HTTP is not a required protocol, but one constructed that meets the constrains. You can build your own! (and make it standard).
William Martinez.

Glossary

Written by: William Martinez
Published on April 26th, 2008 @ 06:31:45 pm , using 448 words at here

During all these discussions, in this blog and other forums, I have found some semantic dissonance. This means some people use the same word and even the same concept, but actually understand different things from it.
So, words like architecture and design mean paper to some and process to others; they may be normal, unnecessary or even offensive. This is a little post that tries do define some of the words I use, just to be sure anybody that reads me understands what my meaning is.

Design: As a verb, is the process of decision making towards the creation of a solution. As a noun, it is the one word name of Design Description.

Design Description: The description of the decisions taken toward a solution and their rationale. It can be a document, image or even multimedia.

Code: Sentences, written in a particular language, that describe the solution. It can be at any level, and may (or not) be executable.

Strategic Design: Design that focus on architecturally significant issues, whose majority are global decisions described in an intensional way.

Tactical Design: Design that focus on tactical issues, whose majority are local decisions described in an intensional way.

Micro Design: Design that focus on operational issues, whose majority are local decisions described in an extensional way.

Domain: Is the set of concepts and relations that define a reality. It is not a description, since those concepts may be infinite or unbounded.

Abstraction: Is the result of abstracting: process of elimination of detail without loosing the essence of the concept being abstracted.

Model: Abstraction of a reality from an specific domain.

Modeling: Process of describing a possible reality in an abstraction level.

Architecture: System Structures, the externally visible properties and the relations between them. NOT PAPER.

System: Independent structure of components interrelated.

Software Intensive Systems. Systems where the majority of the components are software based ones.

Solution: Part or whole of a system that solves a problem from a domain.

Meta something: Meta means beyond, above of, self-referring. Using those concepts of the suffix, we may say meta-modeling is modeling models. Meta-data is data about the data. Meta-language is a language that allows us to describe languages. Meta-comments are comments about the comment. And so on.

Now some notes: from the above, we can say interesting things. For instance, modeling is not a paper generation process, but a description process. Modeling can be use to describe a solution, thus it can also be interpreted as coding. And code, it is not just writing executable lines (in fact, they are not executable, they need more work).

When time and other discussions require it, I will be posting more glossary terms.

Why Web Services Failed at SOA (and why REST may fail too!)

First, let us review what is the concept behind services, with particular mention of the web services themselves.

A service is a business functionality exposed by a simple interface. Note that it is not an object, nor a method, nor a module, not a procedure. It is pure business functionality.

Services are consumed, not called, nor executed nor invoked. We define the service consumption as the interaction between agents, a client and a provider, which will communicate using a messaging system, where the data unit is a document. Consumption may be local or remote (meaning a service may not require remote communication).

A service may live in the web, where they are modeled as resources, identified by a URI. If not living in web, as suitable endpoint implementation should be provided.

A service is described at business level with a contract, where a glossary of the terms is agreed upon, and the semantics of all business concepts and processes are clearly stated and known by interacting parts (this is important). The service implementation is defined by the service name, its contract, an endpoint (unique entry point/port) where to send messages, the operations the service offers, the message interaction flow, the message composition (including the document definition) and optionally a binding information.

Nice definition. What is wrong with it?. Not much, actually. Just that when Web Services Architecture group decided to make those concepts into a standard, they did a great job, but also committed a couple of fatal mistakes.

The first one was the actual selection of SOAP as the messaging protocol. Yes, SOAP is a big mistake, not because it is SOAP, but because of what it was created for. You can read here a very complete explanation of the SOAP origins by one of the people that worked on it, Don Box. There, we can understand the main problem to solve was creating a protocol to better support RPC (actually RMI) in a object distributed system.

Yes, SOAP (Simple Object Access Protocol) was not created to support services documents and messaging. It was created to provide a technology neutral data/class definition system, plus supporting remote method access (that actually meant Remote Method Invocation).

So, why is this a mistake? Well, unless your idea of services was, from the beginning, that of distributed objects and the exposition of their methods, SOAP was no fit for a Services architecture. Why is SOAP there, not sure, but my common sense tells me it was not its place. If the idea was to support document oriented messaging, an RPC protocol was the weirdest decision I can think of. You will need to tweak the protocol to support what it was not supporting before. The only reusable aspect is that it was meant for HTTP transportation, which by the way is not a constrain of the WSA (it is the only implementation though).

History tells that soon after, SOAP was modified to allow document style definition, relaxing the literal RPC format. The SOAP acronym meaning was actually changed! So it is not an object access oriented protocol anymore, but a service oriented one. That should prevent people using it for RPC, was the hope.

Ok, if that was fixed (SOAP adjusted), we may have no more problems with that, right?
What is the second mistake?

Well, a subtle one: they kept the RPC idea in SOAP. Backwards compatibility? Not sure, but the RPC literal was there, in SOAP. Worse, the WSDL included that option and WSA did not discouraged the practice! I may think it was because there were tools supporting this and the idea was not banning anyone from using them. So, people started (or continued) using RPC and calling them services!
Is that wrong? Well, a little:
a. The problem is RPC is not Services,
b. RPC does not share the service metaphor,
c, RPC has different implementation side effects,
d. RPC usually forces fine grain while Services try the contrary
e. RPC couples (per method name, parameters and interaction)
f. RPC is in the IT domain, while services should be in the business one (this is a big one).
g. RPC usually works in the distributed environment, but services not are always distributed.
h. RPC forces request-response flow, while services may have any combination of flows.
i. RPC is usually blocking, synchronous. Services are asynchronous per messaging basic concepts.
j. RPC parameters usually require serialization of objects (to be passed as parameters). Services do not even know what objects are nor the parameter concept, they deal with plain messages. 
k. In HTTP, as a particular implementation, RPCs mapping of concepts adds overhead to the call, while Services uses HTTP just as a transport and should not add more overhead.

Ok but, what about that? In case the RPC was kept due to tools, the existing tools at that time may be kept as RPC tools, and new tools to work with services and their concepts should had been created. Easy solution.

But that didn’t happen.

Actually, the tools took over and started to fight back! There was almost no support for document style. There was an RPC style non encoded. There was no standard way to represent a document (that you can feed the service call with).  Yes, the tools claim they supported document style. But when I did some research projects to compare the tools, I found the services created using document styles didn’t work at all! I created a service, then I created a client using the same tool, and the client failed talking to the service! I made it work by manually structuring the XML document to have the first element named as the method that implemented the service! It was RPC all along, and since nobody complained, I assume no one was expecting to work document style.  Well, there were a few.

But the worst comes afterward, with the creation of the Wrapped and Bare modifiers. They are no were in the WSDL nor the WSA. The wrapped is a way to use document style, but doing what I did manually in the lines above: formatting the XML to reassemble an RPC format message! You know what, testing the BARE modifier yield what I suspected: didn’t work.

That means the tools and server vendors are still selling RPC, creating RPC “services” and RPC clients. The ones that supported the document style, did a great job making people stay away from it, like Axis, whose example of RPC is a couple of lines long, but the same example using document style is gross and long, not even I could read.

Ok, granted, the web services implementation are just RPC in disguise. So what? We’ve been using RPC all our lives and we are happy with it, right?

Well, SOA is a style that looks forward to have its structure and components made out of business functionality. Under that assumption, we can build lots of additional features, like business composition (business processes), orchestration, governance, etc. But, for that we need services as business functionality, decoupled by an uniform interface. RPC adds coupling to the mix, since we are adding the object or library concepts (for many, those two are the same!) , the method invocation interaction, the data coupling in the arguments lists, and the stiffness of non-variable method definitions  (just change one argument and all breaks!).

Point (f) above is important. All other features of SOA are built on top of the concept of a business functionality exposed as a service. Governance, composability, visualization, all those work with services, not with function calls. So, as mentioned in point f, what surfaces is IT, not business, and thus the features may not work as expected.

Add to the mix that, to actually create the services, you must be a programmer. Since they reflect the RMI concept, we assume distributions, method and parameter passing knowledge, etc. Even more, the actual code is converted into exposed services, bottom up approach. This will create services shaped as the actual legacy implementation, which may not match the actual business at hand. The top down approach, which should start with the definition of the service at the business domain level, is discouraged. Tools offer not help there (or very little), and only a few architects follow that path. So, the RPC influence is breaking the possibilities of actually taking advantage of the Services metaphor.

Can I say that the whole failure of SOA as a agent of change, an encourager of business over IT in systems, a provider of business valuable concepts like business processes, governance and product composing, is just the intrusion of RPC in the whole dance? May be, but there are other causes as well. Still, SOA may not raise from he tomb if no paradigm shift is achieved.

Wait a minute. REST is in the title, it is another problem in your list? Or is it just the enemy of SOA?

Well, not really. REST is another architectural Style. It was made for a very different problem and I can assure you it is not the replacement of SOA.

It is in the title because of two reasons:
1. People think the problem of SOA were the Web Services using SOAP,
2. and also people believe REST is a simple way of creating the next generation of services.

So, they are adding another point of failure to the new SOA by trying to construct SOA using what they call “RESTFull Services“.

Why is it a fail point? I’ve heard REST services rock!

Well, first I own REST an apology. You see, actually REST has nothing to do with this. The problem is with the wrongly named REST services, which are no more than an API based on HTTP. Now, there could be REST services, but they are much more complex that the ones most people use. And bigger. So, let’s simply call those “Not-So-REST Services” as Web API Services, (WAS? Nice acronym, a provider for one of those would be a WASP!).

Well, our WAS are, as usual, more oriented to functional calls (yes, RPC). There could be a way the WAS achieves a truly service meaning, when using HTTP as the messaging transport, and the Hypermedia as the documents. Yep, it is a nice match. But that requires people thinking on documents and interactions through messages, and they are not doing that. If you check, it is the same old RPC story again.

So, what to do then? Are we doomed, I mean, is SOA doomed?

Not really. We need to understand what a service is about, and provide a suitable implementation that allows developers to work with it without mapping. I mean, why does a service need to implemented as an object method call? It breaks the metaphor and thus breaks design and implementation, making it flawed.
I’m working on a DOSE (Document Oriented Service Engine) implementation in Java, WAS and WSA oriented (WSDL 2.0, that is), with no RPC. The programming model should be quite different that the proxy and RPC model, plus a set of articles to show how design using document orientation for services should be done.

So, stay tuned.

Longer Abstract for TSSJS presentations

DSL and Testing: using JSR in the Polyglot Architecture.
Long ago, we started working with a Client, PushToTest, that has a tool for testing. The main idea of this tool was the ability to repurpose unit tests into functional, load and Monitor tests. It has also a proxy to record all transactions against a web page, so the transactions could be replayed later. At some stage, the intermediate language chosen to script tests and record the transactions was Jython.

Over the years, it was learned that not all people knew Jython, nor Python nor Java. So, other scripts were added, adding support for popular solutions like Selenium and SOAPUI. Still, we found there were cases where developers had code snippets written in their language of heart, by that ruby, scheme, and others. Then the goal of the tool became being as flexible as we could make it, So, JSR 223 was added to the mix using the external implementation in Java 5, and later using the integrated one of Java 6.
The next step in evolution was to create a communication environment, in a way such that complex transactions testing was possible using at each step the appropriate technology. For instance, we may use … to process data files and execute updates to web services using SOAPUI. Later, we will verify the data is updated in the database by issuing a web report request using selenium. To do this, all scripts should share info, communicate. We created DPLs (data production libraries) able to provide sample data to the running tests, across threads (we simulated multiple user using threads). Some scripts were able to execute methods from objects created in other languages, and we were able to create complex scenarios by launching different groups of threads with multiple roles (for instance, some consumers and other providers, or some posting blogs, some others searching, others registering and other running reports).
To create such a complex system, architecture was the key. One part, what we call the polyglot architecture, is a simple abstraction of runners that allow a central controller to run different tools and languages.
Furthermore. For some of our clients, we were in the need to create simplified languages or scripts. We could do some of those things on java or jython, but we would be forcing the client to learn java to actually modify the scripts. In those cases, we created simplistic languages with a handful of operations, that may be run with a particular runner. Yes, those were little DSLs, and the magic of JSR 223 allow us to integrate them seamlessly into the polyglot architecture.

Want to learn more about this? I will try to explain what a practical DSL is, how to use them for testing,  and how to implement a JSR 223 engine for them. From that to the polyglot architecture, it is just a copy step.

What is a REST API, anyway.
Have you ever wondered what an API is? Well, API may be a common used word, but many just give the definition for granted and had had no second thought about it. Now, REST is an architecture style for networked systems. Given that, how would a RESTFul API look like? This is the question we will discuss in the chat. Actually we will see that many of the APIs have not much in common with REST, and that you may be creating a simple web api rather than a full REST one.

Coding vrs Development.

Agile taste for working code over documentation may be misleading to some. As seen in many posts and discussions, it seems that it means no documentation at all for some people. For another group, it means you just need to start coding, nothing else matters. This post is to differentiate plain coding from development, and to explain that working code is more that just executable sentences.

Let’s start by saying that code is the description of a solution in some sort of language. I defend the position that the description of a solution may not be executable. That description is to be read sometimes by the machine, some others by humans, and some others by both. The description has to have an abstraction level. That is, based on the approach we use to describe and to whom, it may be machine language (assembler for instance) or a high level code like a DSL. And we don’t just write ones and zeros because we will need later to revisit that code, and be able to read it and to make changes. Bear with that in mind for later.

Development is not just coding. It involves finding the why in the business needs and decisions, deciding the how we will solve that, actually describe the solution (to stakeholders and to the executors), and verify that solution meets the needs.

One point to clarify here is the executors concept. A solution is not a chunk of code. A solution may be a complex system, that is software intensive. That means it is not just code, it usually contains processes, people, and many other elements. All together are the solution. And that system is to be built in development, not just the code part.

There are several other tasks that should be performed during the development process. As we deal with humans, you need to have people management. A group has always issues, problems, questions. Also, humans need material to work with. Meetings, information, computers, and many other assets. During the development, several decisions should be made, and not just about code: deliverables, QA scheduling, assignments, feature modifications, priorities, etc.

People needs to communicate. Creation of communications channels, management of those, coordination, moderation, etc. Some voices say all that work should be done by developers themselves. Not so sure about that. Some other say that is not needed, we just need code writers to write code. Not sure that works either.

So, so far, I believe development is far more a complex process that just writing code. And coding is far more complex that just writing an executable set of instructions for a machine (Description of a solution, remember?) Thus, I proclaim that coding is not the same as developing.  Let’s continue.

Going back to the coding definition. Some people think that a non executable code is waste. Specifically, design is seen as useless documentation, wasted time. Here then I start to defend what we may call design.

Non executable code is that one that describes de solution, but may not be read be a machine and may not be executed by it. As we mentioned before, the executer may not be a machine, but let’s assume the executable code is executed by a machine not to mess with concepts. Some of that code is the one generated as strategic and tactical description, aka, architectural description and design. If it is not executable, why do we need that kind of code? There are several reasons:

• The ones to design are the developers, why? Because it is a description of the solution, and thus code.
• Executable code is often done quicker when the ideas and major decisions are already made in the design.
• When code is done, it is usually reviewed and almost always changed to improve it. Describing at design level is quicker than writing low level code, and thus fixes and improvements can be made earlier, saving time and effort (changing executable code, large portions of it, may have a great cost and impact).
• Once done, the executable code should be verified. Checking against a high level description helps to verify. If it is different, then it means either the decision at high level or at low level need a review. It is important that both descriptions are kept in synch.
• Why doing the work twice? Because they are different works. Description at high level is used at some time, and the low level description later. But both are used. Missing one means there is something in development that may have more cost later. See next point.
• Development is never finished with complete code delivery. There are always enhancements, additions, changes. To decide why, how and what, it is always important to know what is done, how and why. Reading machine code means almost impossible changes. Reading executable code is possible, but at high cost. Reading a high level description, that was kept in synch, is great.
• Design is not a documentation process, it is a description process that should be used through the development. If design outcome is not used, the it is waste. Design that is done trying to be complete before operational coding, it will also be a waste of time. Design should be made in regular chunks, not to little ones that misses the tactical view, not so big so that you end up making decisions with not enough information.

So, given the ideas above, I want to proclaim that used design is actually working code, and thus, if well done, complies with Agile thinking.