Moving on to the second of the 4 building blocks that underpin the effective working of our modern technology, we come to Design and Development of the Requirement.
The key challenge is “how do we go about getting the solution to the requirement right”?
A requirement should lead to a clear statement of requirement (SOR) that can be delivered internally by an internal service level agreement (SLA) or contracted for externally by a procurement process. That SOR is best met by an outline design proposal and then a detailed design.
Even where ‘smart development' dynamic processes are required using prototyping, it is best to document successful prototypes as a ‘design', otherwise they cannot be effectively supported in operational circumstances and kept operating to deliver business function.
I have seen this concept misunderstood to the extent where what amounted to a collection of business functions expressed as a single PowerPoint was offered as an effective design. From this a number of independent and uncoordinated suppliers were engaged and expected to deliver a complex solution, “hands off” with no further integration effort.
Sadly, when the security team were brought in late, they not unreasonably asked for the detailed design to understand what had been done and to that ensure there were no vulnerabilities in the delivered solution, that the ongoing construction was safe to underpin the business and could be maintained operationally… They were subsequently blamed for delays and redesign, ie, actually producing a design where there was none.
Those responsible for design must accept that this is a stage in delivering something that works and can be managed properly and that the end client loves and wants more of.
Best practice is to incorporate a combined discipline design team including security and database as well as application architects with operation service representatives, who after all are going to have to deliver service using the end result to meet the requirement continuously and profitably.
Together they should ensure that the final design has been shared with the testing and acceptance team, can be tuned and tested, that the application works with the database and security requirements and that bandwidth realities at WAN, internet, LAN and Wi-Fi achieve acceptable speeds.
There is no right and wrong way to incorporate design and development into build and acceptance. Here I have taken build-out and acceptance into Block 3, but a trial and development rig to test design concepts should be introduced into Block 2 activities. Technology solutions are complex, interconnected and interdependent elements that must be designed and proved with initial testing to operate efficiently and safely together. Individual candidate components (hardware platforms, operating systems, database and security components, etc, do not always do what the manufacturers claim and need to be successfully interoperable ‘out of the box'!
Failure to comprehend this or to appoint a prime supplier to be responsible for integration and delivery of an acceptable solution increases the risk of failure.
Software solutions are hugely dynamic and where bespoke are sometimes rushed out to meet marketing imperatives they may contain flaws, bugs and serious vulnerabilities. This vital stage is considered more in Block 3.
We need to ask ourselves the question, “Is the designed solution ‘business critical', and if so, how does it fit within corporate ideas of risk tolerance and business impact if they fail to work properly?”
When designing part of an infrastructure, levels of resilience should be designed in to meet business needs for service delivery, ie, a telephone exchange, data and communications links to emergency services and commercial EPOS systems and cash machines should be immune to flooding. Electricity substations and pumping stations are invariably positioned on low lying waste ground, which is cheap but are in immediate conflict with the requirements of a resilient infrastructure when vulnerable to flooding!
At the end of the design process some simple check backs to the SOR will help. Does it meet the business requirement, can it be built and operated as designed and, as important, is the design extensible?
As we move further into the challenges of the “Internet Of Things” (IoT), some real design and security challenges are appearing. Tiny sensor components are embedded into electrical components that may have a long life but the sensors have a tiny memory, some as small as 8kb, and may not be suitable for an extended design service. When this happens the SOR needs to be revisited for extensibility or resilience or changes in security vulnerability.
Where a design is a complete ‘system' or a substantial portion of it, the design determinants should consider all requirements for safe and successful operational delivery. That means power, communications, hosting and the build-out of all the components together with extensibility and operational adjustment in mind ‘by design'.
The racking, functional separation and alignment, power delivery and cooling with backbone cable and fibre cabinets correctly positioned ‘by design' is also essential. Too often these are poorly specified, left to what can be afforded in the hosting location at the last minute or left to the installation engineer to manage on the day!
Failure to follow these principles down into ‘hosting' is false economy. Done badly it can lead to frustration and frequent downtime; done well it enables the design to be made secure, maximised for operational effectiveness and efficiency and for ease of in-service management.
Detailed “as built” documentation, down to the component level, should be the final part of a design as it flows from development into build and acceptance into service – as we will discuss in Block 3 next week.Contributed by Tony Collins OBE, chairman of the ECA Group.