Archive
White papers from Matt Deacon
White Papers List of white papers that I’ve produced or contributed to over the past few years:
How Secure is your Cloud?
Cloud security is perhaps the number one topic when it comes to cloud computing and this is still definitely the case if you look like meetings like CloudCamp for example. So why then is there not more of a focus on it from the cloud vendors?
In their June report, "Assessing the Security Risks of Cloud Computing" Gartner provided a fairly competent list of questions that customers should raise with their prospective cloud vendors.
1. Privileged user access.
2. Regulatory compliance
3. Data location
4. Data segregation (which includes Encryption)
5. Recovery
6. Investigative support
7. Long-term viability
Although the list is useful, and I especially like number 7 raised in a security context, there are a couple of key points missing, that while they maybe covered in some subtext under these seven items I personally believe they should be raised to the top level. So here’s my additional set of security topics to raise with your vendor:
8. Internal threat management
9. Portability/access
10. SLAs/Penalties
11.Security in depth
Internal threat management
As we all know too well (or should), one of the majority of security threats of traditional data centres comes from within, with the cloud you’re passing this issue on to someone else. So what are the internal threat management procedures of your cloud vendor? How do they safe guard your data from prying eyes? Sure, encryption and segregation are elements that help here, but what are the data centre processes themselves?
Portability/access
A real favourite topic out there that in many ways overtakes the issues of interoperability is that of portability. How do I safeguard my ability to move from one cloud to another? Once my data is in a cloud how easily (expensive, quickly) can I get it off again? Now add to this the question of secure and robust portability and this becomes a really interesting question to ask.
SLAs/Penalties
So if there is a breach of security what is the cloud vendors policy? Is this transparent? Made publically available? What sort of compensation could you expect? Free hours? SLAs are an obvious discussion point with cloud vendors but are seldom discussed in terms of security.
Security in Depth
This is one I particularly like and relates to internal threat management and processes but specifically to the development and creation of the cloud vendor’s infrastructure itself. Clearly clouds just don’t happen, someone has to build them and that means software engineering. Therefore a clear explanation of their cloud development processes should be clearly articulated at a software development level. This is one of the key lessons Microsoft has learnt over the years and one I know well.
So what other security questions would you want answered by your prospective cloud vendor?
SOA: A square peg in a round hole?
It is really interesting when you look back on your blogs over the years and reflect on how your views have changed, and whether anything still remains true given what you know now. Over the past few months I’ve been researching the state of SOA today; well over a decade since .NET Web Services arrived on the scene and the term SOA first came to popular attention.
One blog I’ve referred to time and time again in talking about SOA is the one I wrote on SOA Anti-patterns back in 2005. I use these anti-patterns regularly when talking to people and had come to think that their value had never been more significant than they are today given the emergence of the so-called “cloud”. However, I had noticed that they resonated less well with those where SOA was being “successful”. It therefore came as quite a shock when I actually re-read the blog only to find that the core tenet on which these anti-patterns were based was actually proving to be itself one of the core anti-patterns of SOA and why in so many cases SOA has proved unsuccessful.
The anti-pattern was actually described in the opening section where I suggest that the decentralised nature of SOA “left unchecked” could lead to the occurrence of a number of the anti-patterns that I went on on to describe. Unwittingly, I had hit upon one of the core anti-patterns for SOA; the square-peg anti-pattern, it was just that at the time I didn’t realise it.
The square-peg anti-pattern
As I noted back in 2005, SOA is a “decentralised” pattern for integrating distributed systems, but what I didn’t realise at the time and where the true problem turns out to be, is that we insist on trying to fit SOA (the peg) into a “centralised” model of IT (the round hole). This is like holding the same poles of two magnets end to end, they repulse each other, we are simply trying to put two incompatible models of operation together as one.
From a centralised perspective of IT these anti-patterns make sense, but turn the problem on the head and they become less significant and maybe cease to exist. The reality of the problem turns out, not to be one of fitting a square peg into a round hole, but that there are simply no square holes!
For IT and let’s face it, for the really important part; the business, to really take advantage of SOA it needs to give up being the monopoly, it needs to decentralise and devolve control to the services themselves. The result is smaller IT, encapsulated within the service, focused almost entirely on delivering business value for that service, rather than having to pay a high tax to conform to the demands of a centralised IT function.
The three Cs!
So if this is the major problem, then why do it? Why not drop SOA and retain the centralised model for IT? Of course this is an option, but let’s look at it through the lens of the three Cs that Hammer and Champy raised in re-engineering the corporation:
- Customers take charge
- Competition intensifies
- Change becomes constant
IT is subject to the same pressures and has to deliver the service that is required by the business. Your customer demands the ability to be more in control, dynamic, they have choice and increasingly have the potential to ‘shop elsewhere’. The competition from others who can provide the service, faster, cheaper and to order is increasing. The rate of change required by your customer grows daily and the need for IT to move from reactive to proactive and part of driving business.
Specialised Units of Business Capability
In looking at the trends within the business itself, one can see it is differentiating into often finer units of specialism. the benefit being, to take advantage of market leading innovation quicker, cheaper and at lower risk. IT needs to power these new capabilities, but can’t do so through a rigid model of centralised command and control. These new capabilities need to move fast, grow fast and evolve quickly in response to change. The IT needs to be as close to that business innovation as possible and be part of the solution rather than a problem that slows down their time to react.
The rise of the Central IS function?
So what now for IT? Is it the end of IT department? Well may be it is, as we know it today. Decentralisation is inevitable for Business as it is for IT, as the technology layers commoditise there is less need for many of the old functions of IT, but given all these moving parts, these increasing units of specialised business capabilities, the increasing number of sourcing choices for services of all shapes and sizes, it is clear that there is a need for:
- co-ordination
- governance
- compliance
- innovation management
These, then become the watch words for the future of the centralised IT function, but it is perhaps the name that needs a change, it is less about the technology but still about the information and management and certainly needs to nurture innovation and of course it’s all about the service.
Welcome to the:
Corporate Information and Innovation Management Service.