As part of my role I help our organization support a variety of clients and in many cases problems get escalated to me – others looking for advice. For me it’s surprising how many organizations architect without agreed upon service level objectives – at the moment this is an art and not a science! Generally companies skip this stage or apply little rigor and they wonder why, six months down the road their service costs have gone through the roof and their farm(s) are experiencing outages.
This week I’m assisting our outsourcing team with an architecture review whereby the client is demanding a design that stretches design metrics well beyond the theoretical limits. Why? Lack of governance, user training, standards, relationship management etc… to name a few. So how did we manage this? With the correct ammunition (An SLA, Technical Design to name a few…) and a well scripted escalation plan. The technical design must reference capacity/performance requirements, known practices for scaling and what the client is willing to pay – it always comes down to money. The escalation plan is in reference to your SLA – functions, features, responsibilities, performance, capacity and costs. This blog provides questions for a top down architecture that might also help you.
The following are some links that provide more detail and will hopefully help you if a similar problem arises in your organization:
- Contextual design
- Developing a content strategy
- Service Level Objectives
- Estimate performance and capacity requirements
- Plan for Software Boundaries
- Additional planning factors
- Tools for testing performance and capacity
- Why project fail
So with this information you can derive a technical design. But wait! Where do we get the technical information for our design? Information architecture, information management policy, security policy and capacity planning…these are subjects for another blog or two!