Demystifying architecture for non-enterprise organizations

Have you got a map?

  • alert
  • submit to reddit

High performance access to file storage

Workshop Architecture, schmarchitecture... words like “architecture” get banded around in IT like they have a specific meaning, when in reality you’d get ten different definitions from ten different people if you asked. But few would agree that IT should do without some degree of ‘structure’, be it mere forethought or understanding about what is required or in place.

IT architecture, in principle, is a good thing. Indeed, when we asked you just over a year ago about the role of the IT architect, we found that while plenty of you were dissing them, few had a problem with the idea of IT architecture per se.

The trouble is, if you actually decide you want some of it (“we have IT architecture in several colors, sir”) you almost immediately hit a brick wall. Documented approaches to IT architecture tend almost immediately to big frameworks and complex, boil-the-ocean approaches that are only really going to be applicable in larger organizations - and even then probably only in moderation.

Of course, I’m saying this in the knowledge that “experts in the field of IT architecture” would push back on the idea that it needs to be hard, onerous, over-complicated or whatever. In my experience, people with 10+ years of experience in any field will be able to pull out the good bits and make it suitable for the need at hand: such people will also be perceived as having sufficient gravitas to be trusted, so that what they say will often be implemented.

However, for the majority of non-enterprise organizations which don’t have access to “the knowledge”, either in document or guru form, deciding where exactly to start with IT architecture can be difficult: it’s a wood-for-the-trees issue.

Where to start with IT architecture?

The good news is, it doesn’t have to be so hard, starting with the recognition that IT architecture is a means to an end. Poorly architected IT environments tend to suffer from more downtime than those for which resilience has been built in from the start (as illustrated in one of our reports). They will also be more costly to administer and deliver lower levels of service. IT architecture is not the solution to all these ills – just having a well structured environment will only get you so far. It does however offer the starting point for doing a better job, more efficiently. So, a key first element is to understand:

• What you have in place in terms of IT systems and resources, physical and logical

• What services you are delivering to your business users

• What information repositories you have

• And what dependencies exist between all three – systems, services and information

This much may sound obvious enough, but we are frequently reminded that few organizations actually have a clear understanding of any, never mind all of the above. Attaining this understanding needn’t be a very onerous exercise, either, particularly if you start with the Pareto principle in mind: can you identify the 20% of your IT facilities that deliver 80% of the value?

Key to this kind of exercise is to remember the ‘means to an end’ factor. If you haven’t already documented what you have, we’re pretty confident that just doing so will turn up some things which merit attention. If so, you’re already in a far better place to take forward existing and planned projects.

The next step: Understanding service delivery characteristics

The next level of “architectural capability” – if we can call it that – takes us from the map of what exists today towards an environment which is most appropriate to your own business needs. For example, your systems may need to support high volumes of transactions, or perform to specific availability criteria. The key question here is “What services does your organization want to provide, and therefore, what services does IT need to support?”

A few years ago I was involved in an exercise extending a software development methodology (RUP, if anyone’s interested) to take into account the broader context of business and IT. At one end, this required an understanding of what the business was trying to achieve – in process terms, or quite simply, in terms of the services it wanted to provide its customers. At the other, it required taking into account the types and structures of systems that would be needed to support the resulting applications: would the database need to run on clustered hardware, for example? Would a failover system need to be in place, and/or would load balancing be necessary across multiple systems?

It’s answers to questions such as these that can help dictate what kind of IT architecture you may need in place or wish to move towards. Today, many answers exist that didn’t before. For example, what we now see as server virtualisation was a mere twinkle in VMware’s eye just a few years ago. As was the idea that some services may be better delivered from third-party, hosted or ‘cloud’ solutions. But even with such innovations, it’s important to start with what you are trying to achieve, rather than what is available out there.

Delivering on IT architecture

All said, IT architecture doesn’t have to be onerous. Indeed, if you work out all the things you are trying to do and then map them against what you have in place, you may find that you want to keep things as they are. Equally, however, you may spot some incremental improvements you can make to your existing environment, or indeed, you may decide more drastic action is required. In all cases, however, at least you will be starting from a clearer point than, “let’s just do it and see what happens” – although most of us will have been guilty of that at some point.

As a means to an end, IT architecture has merit. Indeed, as you build your understanding of what you have, you may turn to well-crafted frameworks such as TOGAF and appreciate their merit.

In the meantime, and especially for non-enterprise organizations, to paraphrase software ‘guru’ Kent Beck, it’s important to recognize that “enough architecture for now is probably enough architecture for now”. ®

High performance access to file storage

More from The Register

next story
Report: Apple seeking to raise iPhone 6 price by a HUNDRED BUCKS
'Well, that 5c experiment didn't go so well – let's try the other direction'
Video games make you NASTY AND VIOLENT
Especially if you are bad at them and keep losing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Zucker punched: Google gobbles Facebook-wooed Titan Aerospace
Up, up and away in my beautiful balloon flying broadband-bot
Nvidia gamers hit trifecta with driver, optimizer, and mobile upgrades
Li'l Shield moves up to Android 4.4.2 KitKat, GameStream comes to notebooks
Gimme a high S5: Samsung Galaxy S5 puts substance over style
Biometrics and kid-friendly mode in back-to-basics blockbuster
AMD unveils Godzilla's graphics card – 'the world's fastest, period'
The Radeon R9 295X2: Water-cooled, 5,632 stream processors, 11.5TFLOPS
Sony battery recall as VAIO goes out with a bang, not a whimper
The perils of having Panasonic as a partner
NORKS' own smartmobe pegged as Chinese landfill Android
Fake kit in the hermit kingdom? That's just Kim Jong-un-believable!
prev story


Mainstay ROI - Does application security pay?
In this whitepaper learn how you and your enterprise might benefit from better software security.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.