The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

The Incremental Architect´s Napkin

How Agility leads to functional design and even TDD
What is it that the customer wants when she orders a software? Behavior. I define behavior as the relationship between input, output, and side effects. It´s like with the Turing Test. When can we consider a machine intelligent? As soon as we cannot tell from a dialog whether the "hidden participant" is a human or not. The Turing Test is about behavior. Requirements are met if some input leads to desired output and expected side effects. This includes performance, security, usability and other aspects. ......

Posted On Saturday, September 27, 2014 9:53 AM | Comments (0) | Filed Under [ The Incremental Architect´s Napkin ]

The Incremental Architect´s Napkin - #7 - Nest flows to scale functional design
You can design the functionality of any Entry Point using just 1D and 2D data flows. Each processing step in such flows contains logic1 to accomplish a smaller or larger part of the overall process. To benefit most from Flow Design, the size of each such step should be small, though. Now think of this scenario: You have a program with some 100,000 lines of code (LOC). It can be triggered through 25 Entry Points. If each started a flow of maybe 5 processing steps that would mean, functional units ......

Posted On Saturday, September 13, 2014 4:45 PM | Comments (0) | Filed Under [ Software design The Incremental Architect´s Napkin ]

The Incremental Architect´s Napkin - #6 - Branch flows for alternative processing
Confronted with an Entry Point into your software don´t start coding right away. Instead think about how the functionality should be structured. Into which processing steps can you partition the scope? What should be doen first, what comes next, what then, what finally. Devise a flow of data. Think of it as an assembly line. Some raw input plus possibly some additional material is transformed into shiny output data (or some side effect fireworks). Here is the Flow Design of the de-duplication example ......

Posted On Saturday, August 30, 2014 11:26 AM | Comments (2) | Filed Under [ The Incremental Architect´s Napkin ]

The Incremental Architect’s Napkin - #5 - Design functions for extensibility and readability
The functionality of programs is entered via Entry Points. So what we´re talking about when designing software is a bunch of functions handling the requests represented by and flowing in through those Entry Points. Designing software thus consists of at least three phases: Analyzing the requirements to find the Entry Points and their signatures Designing the functionality to be executed when those Entry Points get triggered Implementing the functionality according to the design aka coding I presume, ......

Posted On Sunday, August 24, 2014 10:08 AM | Comments (4) | Filed Under [ The Incremental Architect´s Napkin ]

The Inkremental Architect´s Napkin - #4 - Make increments tangible
The driver of software development are increments, small increments, tiny increments. With an increment being a slice of the overall requirement scope thin enough to implement and get feedback from a product owner within 2 days max. Such an increment might concern Functionality or Quality.[1] To make such high frequency delivery of increments possible, the transition from talking to coding needs to be as easy as possible. A user story or some other documentation of what´s supposed to get implemented ......

Posted On Thursday, June 12, 2014 5:26 PM | Comments (1) | Filed Under [ The Incremental Architect´s Napkin ]

The Incremental Architect´s Napkin – #3 – Make Evolvability inevitable
The easier something to measure the more likely it will be produced. Deviations between what is and what should be can be readily detected. That´s what automated acceptance tests are for. That´s what sprint reviews in Scrum are for. It´s no small wonder our software looks like it looks. It has all the traits whose conformance with requirements can easily be measured. And it´s lacking traits which cannot easily be measured. Evolvability (or Changeability) is such a trait. If an operation is correct, ......

Posted On Wednesday, June 4, 2014 5:17 PM | Comments (0) | Filed Under [ Software design The Incremental Architect´s Napkin ]

The Incremental Architect´s Napkin - #2 - Balancing the forces
Categorizing requirements is the prerequisite for ecconomic architectural decisions. Not all requirements are created equal. However, to truely understand and describe the requirement forces pulling on software development, I think further examination of the requirements aspects is varranted. Aspects of Functionality There are two sides to Functionality requirements. It´s about what a software should do. I call that the Operations it implements. Operations are defined by expressions and control structures ......

Posted On Monday, June 2, 2014 12:36 PM | Comments (0) | Filed Under [ Software design The Incremental Architect´s Napkin ]

The Incremental Architect´s Napkin - #1 - It´s about the money, stupid
Software development is an economic endeavor. A customer is only willing to pay for value. What makes a software valuable is required to become a trait of the software. We as software developers thus need to understand and then find a way to implement requirements. Whether or in how far a customer really can know beforehand what´s going to be valuable for him/her in the end is a topic of constant debate. Some aspects of the requirements might be less foggy than others. Sometimes the customer does ......

Posted On Saturday, May 24, 2014 2:45 PM | Comments (0) | Filed Under [ The Incremental Architect´s Napkin ]

Powered by: