When is a brick not a brick

When is a brick not a brick?

When its a building block. A concept, an integral part of a solution design, and a means of resolving complex problems.

Over the years, working within mission critical operational environments, undertaking solution design, or generating scripts and code, the most successful method found has been a methodological approach of breaking a problem down into its component parts.

Faced with architecting a new solution, driving a project or resolving a complex issue the same techniques can always be successfully applied.

Large scale implementations, will more than likely contain a number of inter-dependent components; hardware, could be on premise or cloud delivered. Application delivery will require an underlying operating system and network for communication and possibly also a middleware or database layer, which of course will get more complex if additional contingency or data replication is required.

Those Pesky projects...

Depending on the size of the project and scale of the implementation the solution could consist of a number of teams and a large on premise, hybrid or cloud instance and therefore can only be realistically managed and deployed if broken down its component parts (as we refer back to the affinity of the building block).

This is where the real challenge starts, as soon as we need to break a series of activities down into more manageable tasks, its critical that their is a synergy between the respective teams.

Its a very easy mistake when we 'silo' a large implementation into separate tasks that don't fully identify all the respective associations. We can have an output from one component being a critical input for the next part of the overall 'solution stack'. Another analogy, if we are focusing on the 'brick concept', is that we have a group erecting a house, one team building the walls, another designing the windows and another constructing the roof. We send each team away to undertake their respective tasks but we didn't take into account that all parts need to fit together as a whole. It sounds simplistic, but its a very easy oversight for major projects to encounter, so many dependencies means it a critical factor for implementation success.

If we compare this challenge to an application implementation, we can define the major components in a modular fashion as per the summarised stack below;

• Network Connectivity- Users and associated programs will need to communicate with the application and, dependent on criticality, various independent tools be also be utilised to monitor and log events. A distributed multi-node platform may also be required, therefore it is critical to determine bandwidth requirements and respective interfacing.
• Hardware Platform - Could be on-premise, utilising a virtual instance (local or cloud), a hybrid model or have additional nodes within a contingent multi data centre solution.
• Storage - Most major implementations will utilise some form of Storage Area Network infrastructure, possibly also replicated therefore communication services are a key component across the LAN, WAN and Fibre Channel interfaces.
• Operating System - Independent of the O/S installed, key dependencies will be the underlying network, hardware and associated SAN infrastructure, to ensure a platform that can appropriately host the application.
• Authentication - An important factor of ensuring users can inter-operate with the application and could be undertaken by a separate service i.e. domain or federated accounts.
• Middleware/Database - The overall solution may require some form of database model for hosting and organising critical data. There may also be sharing of memory and disk resources utilised by the operating system, therefore key capacity requirements need to be fully defined otherwise this could generate conflicts for the respective components.
• Application - Finally, once our dependent 'solution stack' layers are in place and effectively communicating, the application can finally be deployed.
• Data Integrity - In supporting the application we need to validate that a 'back-up' of the environment can be undertaken, ideally to a separate entity and restoration of the service if impacted due to data loss.
• Operational Support - A key factor in ensuring the application is always available and re-mediated when required, and can often be an after-thought during project planning and implementations.

As we can observe, a project with an application deployment, has a number of key inter-dependencies and if these tasks are not fully understood and appropriately defined as critical activities then it can have a massive impact on the overall solution delivery.

A successful project implementation will break each key component down into its constituent parts and if multiple teams are required, dependent on the scale of the program, ensure that all inter-related stack inputs and outputs, up and down stream dependencies are appropriately detailed, effectively communicating and delivered.

Michael@thesmallearth.com