Another solution design pattern looking for a base

Its a shame this programme doesn’t have access to a Content Management System, because there are so many aspects of the planning and solution design that are just crying out to be (single source) stored in a structured and related content-base, ready to be pulled out using different views for the various levels of stakeholder.

There are simple elements (such as the list of 8 projects comprising the 47 technical components that will deliver the required scope), where it might make sense to place them into a couple of related tables. Ok, its not so straightforward to create related lists in SharePoint 2003, our current collaboration platform, but at least it’s basic RDBMS style stuff that could be done there give time. However it starts to get far more difficult if you want to try and get the mix of document fragments like multiple paragraphs and bulleted lists to fit into what you know is a useful and logical structure. It will probably become clearer if I describe the type of pattern that I’d like to represent in a content-base.

Project

  • Explain the purpose of this project with a multi-paragraph Description.
  • Give two textual lists of top-level Scope items – those In and those Out
  • Textual list of any Assumptions worthy of mention at this level

All of these are, however, merely an edited summary of what comes in the individual Components delivered as a part of each Project, which leads us on to:

  • Item list of Components this Project comprises

Finally there are a couple of fields that are important considerations for the business case, but are too difficult to break down at a lower level than Project, because they relate to the current state (before we deliver):

  • Paragraph list of Key Differences, outlining what will change most dramatically if we compare before and after
  • Textual list of Benefits that the Project will bring to the service consumers, or to the internal teams that provide the service

Component

As I mentioned, the Project level content fields are just summaries of the Component level fields, so you won’t be surprised to see them repeated:

  • Explain the purpose of the component with a multi-paragraph Description.
  • Give two textual lists of Scope items – those In and those Out
  • Textual list of any Assumptions that need to be aired and perhaps challenged

So far so good? Yes, OK, its a shame that some poor fool has to copy and paste a bit of this between documents, and reconcile differences later, but that’s kind of what happens on change programmes, isn’t it? Well unfortunately yes, but you see there’s more. Because we’re thinking about the way Scope splits and meshes between various Components, and because we want to save this to help with later planning (resource schedules and deliverable deadlines) we also add the following content:

  • Two item lists of Component Dependencies, depending upon and dependant of

I will admit that these are the two senses of the same relationship, but don’t forget this is still a Word document, so we have to do them both manually for now. And because we are locking this valuable information away in the bowels of a word-processed document, then it will merely lead to more copy-paste-reconcile later.

But this is only the start – once the design starts to flow down like a waterfall you start to find all manner of information wants to maintain relationships. These Assumptions may actually have had some influence on what was In or Out of Scope, so that would be a relationship worth tracing. And beyond the realms of this document, into the detailed design, it makes sense to relate the constraints and choices back up to these Assumptions and Scope lists.

Those become valuable notes later when some scope creeps, or any worms turn, later – project change requests are usually more inevitable than exceptional. Yet relying on someone to copy and paste all of this down the design levels is asking for facts to be overlooked. And we all know what are the chances of having both top-level documentation and detailed designs updated properly and in tandem post- change acceptance – a big fat zero.

This is why I say, it seems so lemming-like to load this information into a flat document when it should be drawn out properly across a structured, related content-base, so it flows automatically and efficiently to everyone who needs to know it. Oh well, haven’t got time to sort this out now – our masters have set very tight deadlines for us to reach that jumping cliff. Geronimooooooo!

What’s our standard?

I’m not really obsessed with standards, honestly – it’s just that I find them such a valuable tool when trying to pull almost any kind of system together. A while ago I came up with a framework for creating and using standards, and I’m amazed at how well it has stood the test of time. And the surprising thing is that it’s not just restricted to computing systems, it seems to work for virtually anything you might want to create a standard for.

However it is you want to create and present standards, I find they serve three basic purposes:

  • Define
  • Convey
  • Agree

The common purpose of standards is to get down on a peice of paper what you consider the definition to be. This could be a value, a limit, a logical evaluation, any kind of statement that enables you to say “yes that meets the standard!” or “nope, sorry, not good enough”

Of course the motive for wanting to write it down in the first place is that you want to let others know what your definition is. You know what meets the standard and what doesn’t, but how do you convey this to other people – how do you let them know what is acceptable and what is not?

And of course the thing that actually makes it a standard is the fact that everybody agrees that’s what it is. Ok, maybe the first time you try to define it, there’l be someone who is not quite happy that you have covered everything, so you can qualify your definition further, coming up with a more detailed and precise definition that everybody is happy about. And once you have that acknowledgement or sign-off, then you know you have a standard that is valuable to anyone who might be interested.

Three simple steps, that seem almost too simple, but they work well for any kind of standard you might care to define (and convey to people, and get agreement on, of course) 😉

A cause and effect chain – requirements-driven design

Many people think that working in infrastructure is a very different field from working with applications. From the commercial perspective you are not a revenue generation tool, you are further from business because you merely support other applications, technologically you operate the lower level platform, and users only ever know about you when there is something wrong. Hmmm, that doesn’t sound as exciting as some web-based CRM tool that make financial executives’ eyes light up, especially when they see it on  shiny hand-held devices.

However, if you are trying to approach infrastructure configuration in a vastly different way from how you would approach an application system development project, then you are almost certainly making a rod for your own back.

If you are doing it right, you will:

  • have a separate set of sandpit systems for development
  • keep configurations under version control
  • not release anything until it has been properly tested
  • consider using an established framework,
  • be able to mirror your live back into test for diagnostics
  • be closely involved with key business decision-makers,
  • have a reason for every change you make
  • inform people when you make changes that may affect them

Hmmm, tell me how that differs from applications. And when it comes to applications, you must make sure you get the requirements properly set out in the beginning. Equally so, with infrastructure, requirements must be the starting point for everything. And you should be able to trace back to your requirements so that you understand why things are as they are. If somebody changes one of those requirements you should be able to see how the effects of that change ripple through your systems design down to a final configuration change that you can validate in test.

This is why I propose a cause and effect chain to keep hold of your requirements, and to show what effect they have. This is a typical order for this cause and effect chain…

  • business, functional and financial requirements
  • defined standards (where relevant)
  • environmental / non-functional requirements
  • technical constraints
  • assumptions (stated in lieu of other reasons)
  • design choices
  • implementation detail

This is not definitive nor prescriptive, you might find your ideal chain is defined slightly differently. But its not a bad starting point.
Some people think that system design is some kind of conjuring trick, where a 100 page document is needed to describe the fantastically complex solution that only a quantum physicist would be capable of deriving. Well, actually, complex solutions are more likely to be costly, risky and very difficult to manage going forward.

Don’t get me wrong, I personally love the design part of my work, but all it boils down to is the simple matter of following logical outcomes. If you follow down the cause and effect chain, the right result just pops out at the bottom. And that’s the magic – its simple, like the beautiful magic of nature – its not some black magic, hocus pocus, obscure set of incantations from someone trying to shroud themselves in mystery to occult the fact that they are not really sure how they are managing to make it work.

And the other great thing about the cause and effect chain that stems from requirements is that you can write it all down. State what the item (requirement, constraint, choice or outcome) is at each stage, and which preceding items it depends upon, and you allow any capable person at any time in the future to make any alterations that are relevant for the new circumstances. Structured, yet simple.

Just remember to use Plain English, not some arcane hieroglyphics, nor the latest technobabble.

Remote laptops? You’d be safer with RDP

I have thought about the myriad ways you can protect your core network from remote devices, and I think that you might be surprised to hear that something as obtuse as remote desktop clients could allow you to isolate your network from any device that is not totally under your control.

Publishing applications using web services allows you to restrict the access a client needs via the public internet to a very controllable port number and limited range of ip hosts. For example iNotes allows people from outside the core network to work with Lotus Notes from a browser. Their route in is specific and defined, yet their email integration makes them feel a part of our internal network. You solve your security issue by giving only enough access to do just what they need, a fine principal.

Well we all know how limited some web applications can be, so surely you couldn’t do that for all applications – I mean, if a staff member needed to be able to do ANY part of their day job all of a sudden, from absolutely any internet connected PC, how could they? Well, what RDP gives you is browser-based access to a Terminal Server that you can load up with just those apps someone needs to be able to run. You treat it like a desktop client, but its available to anyone who is running IE and can connect from the internet to a server (farm) via port 3389 (or other if you want to hide it) and has the credentials. And the thing is that you get what looks and acts just like your windows desktop, direct by logging in from the browser, and you don’t actually need much bandwidth to run it.

Remote Desktop Protocol is like a KVM switch that traverses the internet. You operate the mouse & keyboard, and see the responses on the screen in your browser, but all of the processing, all of the file access, everything you do is carried out from a single securely managed server in one of your datacentres, loaded up with just the applications you need to carry out a specific job and nothing more. You remove risk by granting the rights to do a very precise set of tasks to with a certain set of tools, not some free for all client desktop you have limited control over.I have enjoyed the pleasures of having remote desktop client access for a number of years in various companies. And I have been the involved in successfully deploying most of those services for those customers. Once you see that using Terminal Servers is so simple, as easy as smoke and mirrors, you can see its such an obvious solution for so many current headaches in providing people outside your perimeter to have access to what’s inside it. To do only what you allow them to. To do it with only the tools you allow them to use. And you allow this only to people you want to.

Security is about choosing when to allow a person to do something specific – it’s not about trying to prevent everyone else from doing the things you don’t want them to all of the time.