I’ve not been here for long. Not because I wouldn’t have had things to say – I actually had to say a lot, but it all went into our company’s architecture documentation. 100s of pages of high level designs, dependencies, relations, segregations, inputs, outputs, … and all of that boring stuff. Down the track of this work, one of the most important conversations with stakeholders and builders all-the-same was the one of the

Bottom-up versus top-down approach

Obviously – as with everything in life (well: nearly everything) – there’s 2 approaches to create blueprint documents/specifications and build the needed services accordingly: Bottom-up and top-down. In our case, the question arose wrt the framework of delivery support systems (operations support as well as business support systems) and the process of building/integrating them.

The bottom-up approach focuses first on a few requirements to be defined in order to set expectations, then builds the stack according to the respective phase’s needs and derives the definitions accordingly. This approach is more “chaos” and ad-hoc driven and might serve a demo-led approach; at the same time it bears a few significant risks:

• effort and cost consumption without properly defined product and architecture strategy
• build and throw-away effects due to late findings
• build and accept; i.e.: a prototype might be considered more mature than it actually is (under the hood) which would later result in very poor and endangering service quality
• increased effort for keeping information through working teams synced
• missing the point where neither the architecture not its Operations scale anymore and where a change of approach/setup is necessary (especially wrt OPS)

While the bottom-up approach clearly has the advantage of more rapid delivery and market-entry, it seriously endangers technical debt to be created:

Technical Debt (as defined by Ward Cunningham):

“If we failed to make our program align with what we then understood to be the proper way to think about our fin objects, then we were going to continue to stumble on that disagreement which is like paying interest on a loan.” – Ward Cunningham (http://agile.dzone.com/articles/understand-high-cost-technical)

Hence, as a pre-requisite for this approach to be working, one must seek upfront clarity about

• which ecosystem/framework services to build
• around which products
• which relations to create – and (!) maintain

which within the top-down approach might evolve and shape during the pyramid’s first layer. The top-down approach also has the advantage of an all-know-all effect which can allow for utmost work parallelity while at the same time ensure compatibility of built entities. Its risk – however – is first and foremost the late creation of content/deliverables, hence later demo, later feedback, later market-entry, etc…

Phase-mode

Additional complexity is added when building the above in phases; i.e. from limited functionality offered to a limited amount of users in a first phase (e.g. Alpha) to offering full functionality at the final V1.0 release.

NOTE: Assuming a fully balanced build process, I would highly recommend a kanban-style build approach beginning with version 0.1 of the product or framework; assuming that fully balanced process, continous enhancements through continous deployment on a high patch/upgrade rate per day/week/month would be possible. However, even with that balanced process, the following is applicable allthesame.

Both approaches can be driven in a phased-mode in more or less the same way; i.e. in none of the 2 the full set of specifications (or backlog entries respectively) need to be created in order to start into the pyramid’s next layer. It is sufficient to create as much content as for a particular phase needed.

In both phases – though – it is essential to have a basic set of guidelines (like e.g. segregation of duties, purpose of buildling blocks) crystal clearly created so that anybody within any working team is able to align his/her work with these guidelines, perceive, recognise and acknowledge deviations and understand where alignment with other parties is crucial for ongoing success. It is the purpose of the first set of specifications to ensure these guidelines and clarity.

“… the whole debt metaphor or lets say the ability to pay back debt and make the debt metaphor work for your advantage depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.” (http://agile.dzone.com/articles/understand-high-cost-technical)