Why taking good holidays is good practice

Back when I was a fairly recent graduate I received one of the best pieces of advice I've ever received.  The project was having some delivery pressures and I was seen as crucial to one of the key parts.  As a result my manager was putting pressure on me to cancel my holiday (two weeks of Windsurfing bliss in the Med with friends) with a promise that the company would cover the costs.  I was called into the BIG boss' office with the full expectation that he would put the screws on further and in my head I had a list of additional demands.

"Steve, I've heard that XXX [name redacted] wants you to cancel your holiday"
"Yes, we've got to get the release out and I'm the one who knows most about resolving issues in the team"
"Don't"

This kind of stumped me so I sat there a bit quiet, and here came the best advice ever

"If you cancel this holiday then all anyone will remember is that they can make you cancel holidays, they won't actually appreciate it.  If you go on holiday and it all collapses all everyone will remember is that it collapsed without you, if it goes badly or much harder because you aren't there they will remember that, and if its OK without you then hopefully you have enough talent to not insist that the universe revolves around you.  Go on holiday, don't be contactable and remember that now more senior folks know about you because you didn't cancel your holiday."

Its a mantra I've lived by.  Take your holidays, plan to take them, and take them PROPERLY.  That means

1. Change your password before leaving and DON'T update it on any mobile devices
2. Your work laptop does NOT travel on holiday with you
3. You don't do conference calls, standups, "just 30 minutes a day" or any other nonsense.

Since I've become a manager I think this is more important.  If I can't manage and succession plan to the level that the universe doesn't collapse while I'm away then what sort of manager am I?  I actually look very badly on folks who don't take holidays properly as they risking promoting a "macho hero" culture rather than a decent work/life balance culture.  If you don't recharge your batteries properly, spend proper time with your family then really, what is the point?

Planning for holidays is a sign of good planning, requiring people to cancel holidays is a sign of bad planning.  Requiring yourself to cancel holidays is a sign of extremely bad planning and bad succession management.

If you are so bad a manager that your team can't cope for 2 weeks without you, then you need to look at how you are developing your next level.  If you are so scared that people won't "miss" you when you are out of the office then you really need to check yourself and look at your career ambitions and direction.

Taking a good holiday (vacation for my American colleagues) is one of the key reasons WHY we work, explore the world, meet new people, do new things, RELAX. 

Back to the story at the top, I came back after the holiday to see issues lists and problems, it took 4 days of hard work to get us back to level and everyone saw me as the hero.  Had I cancelled my holiday none of the management team would have known how crucial I was to the team's success, because of the holiday I was rapidly promoted into a new role.  As a developer taking that holiday led directly to people appreciating much more what I did for the team.

These days a key success factor for my team is how they cope brilliantly when I'm not there, I'm not worried that this means I'm irrelevant, it means that as we grow and take on new challenges my leadership team is able to grow and develop and take those challenges on, leaving me free to work on what is next.

Good holidays are good practice.

Security Big Data - Part 7 - a summary

Over six parts I've gone through a bit of a journey on what Big Data Security is all about.

1. Securing Big Data is about layers
2. Use the power of Big Data to secure Big Data
3. How maths and machine learning helps
4. Why its how you alert that matters
5. Why Information Security is part of Information Governance
6. Classifying Risk and the importance of Meta-Data

The fundamental point here is that encryption and ACLs provide only a basic hygiene factor when it comes to securing Big Data.  The risk and value of information is increasing and by creating Big Data solutions businesses are creating more valuable and therefore more at risk information solutions.  This means that Information Security needs to become a fundamental part of Information Governance and that new ways of securing that information are required.

This is where Big Data comes to its own rescue through the use of large data sets which enable new generations of algorithms to identify and then alert based on the risk and the right way to handle it.  This all requires you to consider Information Security as a core part of the Meta-data that is captured and governed around information.

The time to start thinking, planning and acting on Information Security is now, its not when you become the next Target or when one of your employees becomes your own personal Edward Snowden, its now and its about having a business practice and approach that considers information as a valuable asset and secures it in the same way as other assets in a business are secured. 

Big Data Security is a new generation of challenges, and a new generation of risks, these require a new generation of solutions and a new corporate culture where information security isn't just left to a few people in the IT department.

Securing Big Data Part 6 - Classifying risk

So now your Information Governance groups consider Information Security to be important you have to then think about how they should be classifying the risk.  Now there are docs out there on some of these which talk about frameworks.  British Columbia's government has one for instance that talks about High, Medium and Low risk, but for me that really misses the point and over simplifies the problem which ends up complicating implementation and operational decisions.

In a Big Data world its not simply about the risk of an individual piece of information, its about the risk in context.  So the first stage of classification is "what is the risk of this information on its own?" its that sort of classification that the BC Government framework helps you with.  There are some pieces of information (The Australian Tax File Number for instance) where their corporate risk is high just as an individual piece of information.  The Australian TFN has special handling rules and significant fines if handled incorrectly.  This means its well beyond "Personal Identification Information" which many companies consider to be the highest level.  So at this level I'd recommend having Five risk statuses

1. Special Risk - Specific legislation and fines apply to this piece of information
2. High - losing this information has corporate reputation and financial risk
3. Medium - losing this information can impact corporate competitiveness
4. Low - losing this information has no corporate risk
5. Public - the information is already public

The point here is that this is about information as a single entity, a personal address, a business registration, etc.  That is only the first stage when considering risk.

The next stage is considering the Direct Aggregation Risk this is about what happens when you combine two pieces of information together, do that change the risk.  The categories remain the same but here we are looking at other elements.  So for instance address information would be low risk or public, but when combined with a person that link becomes higher risk.  When looking at corporate information on sales that might be medium risk, but when that is tied to specific companies or revenue it could become a bigger risk.  Also at this stage you need to look at the policy of allowing information to be combined and you don't want to have a "always no" policy.

So what if someone wants to combine personal information with twitter information to get personal preferences?  Is that allowed?  What is the policy for getting approval for new aggregations, how quickly is risk assessed and is business work allowed to continue while the risk is assessed? When looking at Direct Aggregation you are often looking at where the new value will come from in Big Data so you cannot just prevent that value being created.  So setting up clear boundaries of where approval is required (combining PII information with new sources requires approval for instance) and where you can get approval after the fact (sales data with anything is ok, we'll approve at the next quarterly meeting or modify policy).

The final stage is the most complex its the Indirect Aggregation Risk that is the risk of where two sets of aggregated results are combined and though independently they are not high risk the pulling together of that information constitutes a higher level risk.  The answer to this is actually to simplify the problem and consider aggregations not as just aggregations but as information sources in their own right. 

This brings us to the final challenge in all this classification: Where do you record the risk?

Well this is just meta-data, but that is often the area that companies spend the least amount of time thinking about but when looking at massive amounts of data and particularly disparate data sources and their results then Meta-Data becomes key to big data.  But lets look just at the security side at the moment.

Data	Type	Direct Risk
Customer	Collection	Medium
Tax File Number	Field	Special
Twitter Feed	Collection	Public

and for Aggregations

Source 1	Source 2	Source 3	Source 4	Aggregation Name	Aggregation Risk
Customer	Address	Invoice	Payments	Outstanding Consumer Debt	High
Customer	Twitter	Locaiton		Customer Locations	Medium
Organization	Address	Invoice	Payments	Outstanding Company Debt	Low

The point here is that you really need to start thinking about how you automate this, what tools you need.  In a Big Data world the heart of security is about being able to classify the risk and having that inform the Big Data anomaly detection so you can inform the right people and drive the risk.

This gives us the next piece of classification that is required which is about understanding who gets informed when there is an information breach.  This is a core part of the Information Governance and classification approach, because its hear that the business needs to say "I'm interested when that specific risk is triggered".  This is another piece of Meta-data and one that then informs the Big Data security algorithms who should be alerted.

If classification isn't part of your Information Governance group, or indeed you don't even have a business centric IG group then you really don't consider either information or its security to be important.

Other Parts in the series

1. Securing Big Data is about layers
2. Use the power of Big Data to secure Big Data
3. How maths and machine learning helps
4. Why its how you alert that matters
5. Why Information Security is part of Information Governance

Securing Big Data Part 5 - your Big Data Security team

What does your security team look like today?

Or the IT equivalent, "the folks that say no".  The point is that in most companies information security isn't actually something that is considered important.  How do I know this?  Well because basically most IT Security teams are the equivalent of the nightclub bouncers, they aren't the people who own the club, they aren't as important as the barman, certainly not as important as the DJ and in terms of Nightclub strategy their only input will be on the ropes being set up outside the club.

If Information is actually important then information security is much more than a bunch of bouncers trying to keep undesirables out.  Its about the practice of information security and the education of information security,  in this Information security is actually a core part of Information Governance and Information Governance is very much a business led thing.

Big Data increases the risks of information loss, because fundamentally you are not only storing more information you are centralizing more information which means more inferences can be made, more links made and more data stolen.  This means that historical thefts which stole data from a small number of systems risk being dwarfed by Big Data hacks which steal huge sets or even runs algorithms within a data lake and steals the results.

So when looking at Big Data security you need to split into three core groups

The point here is that this governance is exactly the same as your normal Data governance, its essential that Information Security becomes a foundation element of information governance.  The three different parts of governance are set up because there are different focuses

1. Standards - sets the gold standard of what should be achieved
2. Policy - sets what can be achieved right now (which may not meet the gold standard)
3. KPI Management - tracks compliance to the gold standard and adherence to policy

The reason these are not just a single group is that the motivations are different.  Standards groups set up what would be ideal, its against this ideal that progress can be tracked.  If you combine Standards groups with Policy groups you end up with Standards which are 'the best we can do right now' which doesn't give you something to track towards over multiple years.

KPI management is there to keep people honest.  This is the same sort of model I talked about around SOA Governance and its the same sort of model that whole countries use, so it tends to surprise me when people don't understand the importance of standards v policy and the importance of tracking and judging compliance independently from those executing.

So your Big Data Security team starts and ends with the Information Governance team, if information security isn't a key focus for that team then you aren't considering information as important and you aren't worried about information security.

Other Parts in the series

1. Securing Big Data is about layers
2. Use the power of Big Data to secure Big Data
3. How maths and machine learning helps
4. Why its how you alert that matters

Securing Big Data - Part 4 - Not crying Wolf.

In the first three parts of this I talked about how Securing Big Data is about layers, and then about how you need to use the power of Big Data to secure Big Data, then how maths and machine learning helps to identify what is reasonable and was is anomalous.

The Target Credit Card hack highlights this problem.  Alerts were made, lights did flash.  The problem was that so many lights flashed and so many alarms normally went off that people didn't know how to separate the important from the noise.  This is where many complex analytics approaches have historically failed: they've not shown people what to do.

If you want a great example of IT's normal approach to this problem then the ethernet port is a good example.

What does the colour yellow mean normally? Its a warning colour, so something that flashes yellow would be bad right?  Nope it just means that a packet has been detected... err but doesn't the green light already mean that its connected?  Well yes but that isn't the point, if you are looking at a specific problem then the yellow NOT flashing is really an issue... so yellow flashing is good, yellow NOT flashing is bad...

Doesn't really make sense does it?  Its not a natural way to alert.  There are good technical reasons to do it that way (its easier technically) but that doesn't actually help people.

With security this problem becomes amplified and is often made worse through centralising reactions to a security team which knows security but doesn't know the business context.  The challenge therefore is to categorize the type of issue and have different mechanisms for each one.  Broadly these risks split into 4 groups

Its important when looking at risks around Big Data to understand what group a risk falls into which then indicates the right way to alert.  Its also important to recognize that as information becomes available an incident may escalate between groups.

So lets take an example.  A router indicates that its receiving strange external traffic.  This is an IT operations problem and it needs to be handled by the group in IT ops which deals with router traffic.  Then the Big Data security detection algorithms link that router issue to the access of sales information from the CRM system.  This escalates the problem to the LoB level, its now a business challenge and the question becomes a business decision on how to cut or limit access.  The Sales Director may choose to cut all access to the CRM system rather than risk losing the information, or may consider it to be a minor business risk when lined up against closing the current quarter.  The point is that the information is presented in a business context, highlighting the information at risk so a business decision can be taken.

Now lets suppose that the Big Data algorithms link the router traffic to a broader set of attacks on the internal network, a snooping hack, this is where the Chief Information Security Officer comes in, that person needs to decide how to handle this broad ranging IT attack, do they shut down the routers and cut the company off from the world?  Do they start dropping and patching, and do they alert law enforcement.

Finally the Big Data algorithms find that credit card data is at risk, suddenly this becomes a corporate reputation risk issue and needs to go to the Chief Risk Officer (or the CFO if they have that role) to take the pretty dramatic decisions that need to be made when a major cyber attack is underway.

The point here though is that it needs to be systematic how its highlighted and escalated, it can't all go through a central team.  The CRO needs to be automatically informed when the risk is sufficient, but only be informed then.  If its a significant IT risk then its the job of the CISO to inform the CRO, not for every single risk to be highlighted to the CRO as if they need to deal with them.

The basic rule is simple: "Does the person seeing this alert care about this issue? Does the person seeing this alert have the authority to do something about this issue? and finally: does the person seeing this alert have someone lower in their reporting chain who answers 'yes' to those questions?"

If you answer "Yes, Yes, No" then you've found the right level and then need to concentrate on the mechanism.  If its "Yes, Yes, Yes" then you are in fact cluttering if you show them everything that every person in their reporting tree handles as part of their job.

In terms of the mechanism its important to think on that "flashing yellow light" on the Ethernet port.  If something is ok then "Green is good", if its an administrative issue (patch level on a router) then it needs to be flagged into the tasks to be done.  If its an active and live issue it needs to come front and center.

In terms of your effort when securing Big Data you should be putting more effort into how you react than on almost any other stage in the chain.  If you get the last part wrong then you lose all the value of the former stages.  This means you need to look at how people work, look at what mechanisms they use, so should the CRO be alerted via a website they have to go to or via an SMS to the mobile they carry around all the time and that take them to a mobile application on that same device? (hint: its not the former).

This is the area where I see the least effort made and the most mistakes being made, mistakes that are normally "Crying Wolf" so you show every single thing and expect people to filter out thousands of minor issues and magically find the things that matter.

Target showed that this doesn't work.

Securing Big Data - Part 3 - Security through Maths

In the first two parts of this I talked about how Securing Big Data is about layers, and then about how you need to use the power of Big Data to secure Big Data.  The next part is "what do you do with all that data?".   This is where Machine Learning and Mathematics comes in, in other words its about how you use Big Data analytics to secure Big Data.

What you want to do is build up a picture of what represents reasonable behaviour, that is why you want all of that history and range of information.  Its the full set of that across not single actions but millions of actions and interactions that builds the picture of reasonable.  Its reasonable for a sys-admin to access a system, its not reasonable for them to download classified information to a USB stick.

A single request is something you control using an ACL, but that doesn't include the context of the request (its 11pm, why is someone accessing that information at all that late?).

You also need to look at the aggregated requests - They've looked at the next quarters sales forecast while also browsing external job hunting sites and typing up a resignation letter.

Then you need to look at the history of that - Oh its normal for someone to be doing that at quarter end, all the sales people tend to do that.

This gives us the behaviour model for those requests which leads to us understanding what is considered reasonable.  From reasonable we can then identify anomalous behaviour (behaviour that isn't reasonable).

No human defined and managed system can handle this amount of information, but Machine Learning algorithms just chomp up this sort of data and create the models for you.  This isn't a trivial task and its certainly massively more complex than the sorts of ACLs, encryption criteria and basic security policies that IT is used to.  These algorithms need tending, they need tuning and they need monitoring.

Choosing the right type of algorithms (and there are LOTS of different choices) is where Data Scientists come in, they can not only select the right type of algorithm but also tune and tend it so it produces the most effective set of results consistently.

What this gives you however is business centric security, that is security that looks at how a business operates.  Anomalous Behaviour Detection therefore represents the way to secure Big Data by using Big Data.

The final challenge is then on how to alert people so they actually react.

Securing Big Data - Part 2 - understanding the data required to secure it

In the first part of Securing Big Data I talked about the two different types of security.  The traditional IT and ACL security that needs to be done to match traditional solutions with an RDBMS but that is pretty much where those systems stop in terms of security which means they don't address the real threats out there, which are to do with cyber attacks and social engineering.  An ACL is only any good if people do what they are expected to do.  Both the Target Credit Card hack and the NSA hack by Edward Snowden involved some sort of insider breach, so ACL approaches were part of the problem not the solution.

With Big Data and Hadoop we have another option: to actually use Hadoop to secure the information in Hadoop.  This means getting more information into Hadoop, particularly network and machine log information.

So why do you need all this information?  Well you need obviously to know the access requests and what data is accessed, but you also need to know where the network packets go.  Are they going to a normal desktop or corporate laptop or do they head out of the company and onto the internet?  Does the machine that is downloading information have a USB drive plugged in and the files being copied to it?  Is there a person logged into the machine or is it just a headless workstation?

The point here is that when looking at securing Big Data you need to take a Big Data view of security.  This means going well beyond traditional RDBMS approaches and not building a separate security silo but instead looking at the information, adding in information about how it is accessed and information about where that is accessed from and how.

This information builds up a single request view, but by storing that information you can start building up a profile of information to understand what other information has been requested and how that matches or can be linked.  Thus if someone makes 100 individual requests that on their own are OK but taken in aggregate represent a threat then its the storage of that history of requests that give you the security.

So to secure Big Data we don't need to just look at individual requests, the ACL model, we need to start building up the broad picture of how the information is accessed, what context it is accessed within and where that information ends up.  To secure Big Data, or in reality any data, is about looking at the business context rather than the technical focus of encryption and ACLs which are simply hygiene factors. 

Securing Big Data - Part 1

As Big Data and its technologies such as Hadoop head deeper into the enterprise so questions around compliance and security rear their heads.

The first interesting point in this is that it shows the approach to security that many of the Silicon Valley companies that use Hadoop at scale have taken, namely pretty little really.  It isn't that protecting information has been seen as a massively important thing as there just aren't the basic pieces within Hadoop to do that.  Its not something that has been designed to be secure from day one, its designed to be easy to use and to do a job.  Its as governments and enterprises with compliance departments begin to look at Hadoop that these requirements are really surfacing.

But I'm not going to talk about the encryption and tokenization solutions, those are hygiene factors but not really about securing the information, because its still going to be accessible to people with the right permissions.  Because of that its still at risk from Cyber or Social Engineering attacks.  The means that security for Big Data is about layering and really its about two different ways of viewing security.

IT solutions, technical solutions, can really help around access control, encryption but they don't really help you to actually prevent information being stolen.  What stops information leaking is about the business decisions you make.

The first one of those is: what information do I actually store?  So you might decide that you'll just store IDs for customer information in Hadoop and then use a more traditional store to provide the cross reference of IDs back to customer information when its required.

Above this however is actually using Hadoop to protect Hadoop.  What is Hadoop?  Its a Big Data analytics platform.  What is the biggest threat around Data?  Social Engineering or Cyber 'inside the walls' attacks.  So the first stage in securing Hadoop is to do the IT basics, but the next stage of securing the business of information is about using the power of Hadoop to secure the information stored within it.

Why your IT strategy failed or why the business hates IT

One of the most depressing things in IT is our inability to learn.  From the 'Oh look our massive waterfall project ran over budget' to the 'I really can't maintain the code we wrote that doesn't have a design or documentation' we do the same things as an industry over and over again.  Most depressing however is the phrase 'The IT Strategy would work if the business would just change'.

To illustrate this I'd like to tell you a tale, the names will not be used to protect the guilty but it sums up nicely the lunacy of many IT strategy efforts.

Many moons ago I was working for the business side of a large and very successful company.  This company was seen as a genuine market leader and I was working on some very complex mathematics around predictive analytics that the business folks wanted to make their supply chain run better.  There were two highlights through the process from the IT department.

The first was when discussing how such a solution would be implemented and integrated into the operational systems.  IT had a strategy you see and by strategy I mean they had picked a couple of vendors, the solution I was working on had some very specific requirements and wasn't available from those vendors.  An Enterprise Architect from the IT department said in a pretty well attended meeting

'It doesn't matter what the business wants, if we say it isn't going in, it isn't going in.'

The project continued on however as the business saw value in it and wanted to understand what could be done.  One of the key pieces was that we'd need some changes in how operational processes worked, not big ones but more we'd change the way people worked within the existing processes by giving them better information.  To this end we had a workshop with the business and certain key IT folks and worked out how we'd have to design the interfaces and processes to work within the current business environment and culture.  It was a good workshop and the business folks were very happy.

Then came IT, IT you see had a big strategic project to replace all of the existing systems with 'best of breed' solutions.  I'd always assumed that given the massive budget for that program the business was fully engaged... then this happened....

One of the IT folks chirped up and said : "We need to have a workshop so we can tell you what your new operational processes are going to be"

Note the 'tell'... to which the most senior business guy there (a board member IIRC) said

"How do you mean tell us?"

IT Guy: "The new systems have new processes and we need to tell you what they are so you can change."

Business Guy:"Have you done an impact analysis against our current processes?"

IT Guy: "No we've just defined the Best Practice To-Be processes, you need to do the impact and change management.  We need the meeting so we can tell you what the To-Be processes are"

Business Guy in a voice so dripping with sarcasm I thought we'd have a flood: "I look forward to our IT department telling the business what Best Practice is for our industry."

IT Guy, completely failing to read the sarcasm: "Great we'll get it organised"

This is one of the most visible examples of my career on why IT strategies fail.  I've said before there is no such thing as IT strategy its the job of IT to help automate and improve the business strategy, that means thinking tactically and taking strategy from the business model.

"Culture eats strategy for breakfast"

This is the reality and an IT approach that seeks to drive over the culture and dictate from a position of technology purity will fail.  You can change the culture, its hard and its not a technology thing, but you always need to be aware of the culture in order to succeed.

IT Strategy, if such a thing exists, is there to make the business better not to make IT better.

How Business SOA thinking impacts data

Over the years I've written quite a bit about how SOA, when viewed as a tool for Business Architecture, can change some of the cherished beliefs in IT.  One of these was about how the Single Canonical Form was not for SOA and others have talked about how MDM and SOA collaborate to deliver a more flexible approach.  Central to all of these things has been that this has been about information and transactions 'in the now' the active flowing of information within and between businesses and how you make that more agile while ensuring such collaboration can be trusted.

Recently however my challenge has been around data, the post-transactional world, where things go after they've happened so people can do analytics on them.  This world has been the champion of the single canonical form, massive single schemas that aim to encompass everything, with the advantage over the operational world that things have happened so the constraints, while evident, are less of a daily impact.

The challenge of data however is that the gap between the post-transactional and the operational world has disappeared.  We've spent 30 years in IT creating a hard-wall between these ares, creating Data Warehouses which operate much like batch driven mainframes and where the idea of operational systems directly accessing them has been aggressively discouraged.  The problem is that the business doesn't see this separation.  They want to see analytics and its insight delivered back into the operational systems to help make better decisions.

So this got me thinking, why is it that in the SOA world and operational world its perfectly ok for local domains and businesses to have their own view on a piece of data, an invoice, a customer, a product, etc but when it comes to reporting they all need to agree?  Having spent a lot of time on MDM projects recently the answer was pretty simple:

They don't

With MDM the really valuable bit is the cross-reference, its the bit that enables collaboration.  The amount of standardisation required is actually pretty low.  If Sales has 100 attributes for Customer and Finance only 30 and in-fact it only takes 20 to uniquely identify the customer then its that 20 that really matter to drive the cross reference.  If there isn't any value in agreeing on the other attributes then why bother investing in it?  Getting agreement is hard enough without trying to do it in areas where the business fundamentally doesn't care.

This approach to MDM helps to create shorter more targeted programs, and programs that are really suited to enabling business collaboration.  You don't need to pass the full customer record, you just pass the ID.

So what does this combination of MDM and SOA mean for data, particularly as we want analytics to be integrated back into operations?

Data solutions should look more like Business SOA solutions and match the way the business works

In simple terms it means the sort of thinking that led to flexibly integrated SOA solutions should now be applied to Data.  Get rid of that single Schema, concentrate on having data served up in a way that matches the requirements of the business domains and concentrate governance on where its required to give global consistency and drive business collaboration.  That way you can ensure that the insights being created will be able to be managed in the same way as the operational systems.

With SOA the problem of people building applications 'in the bus' led me to propose a new architectural approach where you don't have one ESB that does everything but accept that different parts of the business will want their own local control.  The Business Service Bus concept was built around that and with the folks at IBM, SAP, Microsoft and Oracle all ensuring that pretty much everyone ends up with a couple of ESB type solutions its the sort of architecture I've seen work on multiple occasions.  That sort of approach is exactly what I now think applies to data.

The difference?

Well with data and analytical approaches you probably want to combine data from multiple sources, not just your own local information, fortunately new (Java) technologies such as Hadoop are changing the economics of storing data so instead of having to agree on schemas you can just land all of your corporate data into one environment and let those business users build business aligned analytics which sit within their domain, even if they are using information shared by others.  MDM allows that cross reference to happen in a managed way but a new business aligned approach removes the need for total agreement before anything can get done.

With Business SOA driven operations we had the ability to get all the operational data in real-time and aggregate at the BSB level if required, with Business SOA driven data approaches we can land all the information and then enable the flexibility.  By aligning both the operational and post-transactional models within a single consistent Business aligned approach we start doing what IT should be doing all along

Creating an IT estate that looks like the business, evolves like the business and that is costed in-line with the value it delivers.

Applying Business SOA thinking to data has been really interesting and what led to the Business Data Lake concept, its early days clearly but I really do believe that getting the operational and data worlds aligned to the business in a consistent way is going to be the way forwards.

This isn't a new and radical approach, its just applying what worked in operations to the data space and recognising that if the goal of analytics is to deliver insight back into operations then that insight needs to be aligned to the business operations from the start so it can adapt and change as the operational business requires.

The boundaries from the operational and post-transactional world have gone, the new boundaries are defined by the business and the governance in both areas is about enabling consistent collaboration.

Quality is a side-effect not the goal in MDM

I put out a tweet the other day with this title and I think its worth elaborating on what I mean.  Lots of MDM efforts I see have the goal of 'improve data quality' and this is a mistake.  I'm not saying that data quality isn't a good thing but that in itself its not actually a goal.

What do I mean?  Well lets take an analogy or three, if you are looking to buy a diamond then do you buy the very, very best and the very very biggest?  If you are looking for diamonds to use in cutting or industrial grinding then the answer is of course 'no', the quality really wouldn't be appropriate in those uses it would be a waste of money.  What if you are looking to put a 1.6 litre engine in a car aimed at the local commuter market, do you look around for the most powerful, most expensive, built to the highest quality standards?  Well that would probably be one of the engines slated to go into a Formula 1 car next season.  Sure it generates huge power and is a quality engine but its not fit for purpose.

Now for the final analogy.  You are looking to provide translation services for the Iranian nuclear discussions.  Should you go and get the cheapest price from someone who promises they can speak 'Iranian' or do you invest from someone who actually is proven as a translator for Persian, Gilaki and Mazandarani and describes their Kurdish as 'passable'?

The point here is that in each case the goal defines the level of quality required, quality in itself is about having an acceptable level of quality to meet your goal which in some occasions might be very little indeed.

So what is the real goal of MDM?  Its about enabling business collaboration and communication the power of MDM is really in the cross-reference, the bit that means you know the customer in one division is the same as another and that the product they are buying is the same in two different countries.  If the quality is awful but the cross-reference works then in many occasions you don't need to invest more in quality unless there is a business reason to do so.  Most of the time that business reason is that you cannot achieve the collaboration without having a decent level of quality.  To match customers across business areas requires you to have an standard definition, so your customer on-boarding needs a certain level of rigour, your product definition needs to work to standards that are agreed across the business.

So in focusing on the collaboration, in focusing on where the business wants to collaborate you focus MDM and you focus where quality needs to be achieves.  Focusing on quality as a goal is a very IT centric thing, focusing on collaboration and through that enabling quality is a business thing.

And MDM is certainly a business thing. 

IT has made its self redundant through technology

There are lots of stats out there about CMOs (Chief Marketing Officers), CFOs and COOs now spending more on IT than the IT department.  Lots of this spend is on SaaS solutions and information centric solutions.  The previously powerful IT department has dropped out of contention in many cases because its not seen as adding any value.

And what is the main reason for that?

Well the IT department, its traditional vendors and analysts really aren't about offering business value, they are about positioning technologies, and of course re-positioning new technologies that do the same things as the old ones but in a 'better' technical way.

But lets look at some business apps for a second and ask some questions

SAP - Is SAP ECC the 'best' technical solution?  I think even the most ardent SAP fans would admit that this isn't the case, but it doesn't matter because what SAP does have is the operational processes the business wants.

SFDC - Is SFDC technically the best?  Is the Force.com development language the best development language?  Are their integration interfaces the very best that they could be...  again I think everyone could point to areas of improvement but again the business doesn't care.

What about the various marketing engines out there?  Indeed what about those things such as AWS or Google AdSense that people point to as technically excellent.  Do business people care about that technical excellence?

No, and No.

The market is changing, people want to get value and that means we need as an industry to concentrate on delivering that value and not on arguing about pieces that no-one cares about.  I talked about this before in Christmas SOA the fact that our job in IT is to deliver the outcome to the business without worrying them about the details of technology otherwise they will buy those outcomes from somewhere else, bleating about the technical imperfection of that other approach carries no weight when you've not demonstrated an ability to understand and deliver the right outcome.

IT needs to switch its focus to the 'I' (Information) and the outcome and stop this obsession with technology.

42 - Or do you understand your Big Data question?

What is the ultimate Big Data question?  Well it is of course the Biggest Question... the question... of Life, the Universe and Everything.... but that poses a problem: in an analytical world do you really understand the question?

(or in short form if you are in a rush)

The point here is that one of the major challenges with Big Data is that we are moving away from simple SQL driven questions 'who are my top ten customers' or 'how much did I sell last week' into much more analytical and predictive questions such as 'if I reduce the price of goats cheese how much more red wine will I sell'

This presents a new set of challenges because analytics can give you simple answers '15% more' which then lead you to drop the price of goats cheese.  The network effect of that change however means less beer is sold and less hard cheese is sold so now you are over stocked in beer and hard cheese, both of which have a use-by date.  The point is that the question was badly formed but correctly answered.  Greater degrees of abstraction also introduce greater degrees of assumption in those creating the models.  So while the business has asked a small and concise question 'where to put the next store' the model has made certain assumptions that may or may not be the case. How are these assumptions shown to the business and if they are can the business even understand them?

Today there exists a problem of chained spreadsheets, in the future the issue of chained analytical models is going to make the connection between the business 'question' and the 'answer' more complex and harder to understand and put more power into the hands of mathematicians who prove good at converting abstract questions into good models.  This also means that there will be ever more importance placed on getting control of the definition of information into that model (what is a customer, what is a product, how do you identify them... MDM stuff) these are the bits that the business can control.  The core information, the sources and the quality control around them.

Big Data answers - only as good as your understanding of the question.

Hackgate and what it teaches us about responsibility

The ongoing Hackgate scandal, we can call it that as people in the US are now interested rather than just the dull old 'phone hacking scandal', teaches us some very interesting lessons about corporate politics and the meaning of the term responsibility.

I see quite a few projects where the issue is that someone somewhere hasn't taken control or responsibility and therefore things have gone off the rails. A lot of the time this is about the personality types involved and those personalities massively impact how any recovery can be achieved.

In this scandal we've seen so far five completely different views of responsibility and each of these teaches us a lesson we can learn from

Responsibility without Action but with blame - David Cameron
First up is the Prime Minister David Cameron who has taken 'full responsibility' for hiring Andy Coulson.  What full responsibility means here is that he has stated that he takes that responsibility, but in reality actually nothing has changed or is in danger of actually being done.  I often see this on projects where a senior business sponsor has a pet project that they actually don't care that much about but just want to see it continue for power reasons.  As with this occasion this responsibility normally actually means shooting the project manager or some other individual so in reality what is being said is that the senior individual actually bears no real responsibility and that the failure is further down the chain of command.

This is very common in IT projects, often you will see a programme director being promoted during a project and then taking 'full responsibility' by firing the person who had to clean up their mess after they were promoted.  Its a very good career strategy as it implies that you are the sort of person who takes decisive action and has person integrity but in reality is classic blame farming.  This is one of the hardest situations to deal with when recovering a project as you often need the sponsor to change some of their behaviours and what you get instead is a continual statement that they have 'taken responsibility' but actually in reality done nothing to change the behaviours that led to them having to take responsibility for the failure. These people can be very useful when you recover a program as they are keen to be seen to be doing things and if you can leverage that into action it can be a positive thing.

Responsibility without responsibility - Rebecca Brooks
Rebecca Brooks (nee Wade) typifies another form of rogue sponsor when issues occur.  In this case the sponsor is often actively involved with the project and seen as more than simply a sponsor but actually a leader of the initiative.  Trouble occurs and the sponsor throws up their hands and claims that they had no idea at all what was going on and are appalled at how they were kept in the dark.  This is a very tricky act to play but if played well normally means that the entire project is about to get a huge kicking as literally nobody is going to protect the individuals and indeed the previous sponsor will often be the most vicious in terms of lashing out in order to protect their own reputation.

In IT programmes I regularly see this where a project within an IT Director's remit is failing and they see that their best chance of coming out well is to be seen as a 'strong' leader who has so many things to do that they can't be faulted for 'trusting' lieutenants who then turned out to be rubbish.  When trying to clean up a project these people are toxic as normally their only interest is ensuring that no blame ever attaches itself to themselves, Brooks' initial leading of the 'investigation' is a classic case of this where someone closely associated with the issues tries to ensure the 'correct' outcome by either directly or indirectly leading the investigation.  Sometimes in IT the phrase 'lets draw a line under it and move on' is used which can help if its meant as it means everyone can get on with fixing the problem rather than with worrying about the political issues.

Responsibility with personal accountability and exit - Sir Paul Stephenson 
Then we have the Met Police chief who has resigned for the faults within his organisation which pretty much no-one feels touch him personally.  His extremely barbed comment pointing out that his mistake was to employ someone who hadn't resigned in the original scandal, as opposed to David Cameron, clearly highlights what he feels is a double standard in how people talk about responsibility.  Now from one perspective having the overall sponsor take responsibility and leaving because of it demonstrates strong personal integrity and leadership, but in another it also means that the folks below are left without a clear leader and therefore there is uncertainty on who will clean things up.

In IT this often unfortunately occurs when the sponsor feels they can leap into another job somewhere else if they go before they are pushed.  The challenge to the project team remains who will clean up the mess and drive it forwards.

No responsibility but lots of finger pointing
What has been most common in this scandal is lots of people from the outside pointing fingers and suggesting how things should be cleaned up, with in the most part very little actual personal commitment in helping to clean things up.  MPs have condemned and moaned, but not promised to stop religiously courting the media.  Other scandal sheets have condemned and moaned about its impact on the reputation of 'good journalism', but certainly not offered up themselves to be investigated to clean their names.

This is really common in IT recovery programmes, lots of people standing on the sidelines with 'helpful' advice on how to improve or how to 'learn' from the mistakes but zero actual time commitment in cleaning things up.  Managing these people is central to recovering an IT programme.

No concept of responsibility
Paul McMullen has been the comedy turn of this scandal, a man so divorced from reality that he continues not just to excuse but positively to champion the sorts of behaviour that everyone is condemning around him.  Here is a man who both Hugh Grant and Steve Coogan have show up to be a total and utter muppet of the highest order.  At some stages I've really wondered if he isn't really a journalist but in fact a very hammy actor who is over playing the part.

In IT these are the folks who just don't get that there is an issue.  I once interviewed an architect shortly after Boo.com had failed.  He had been responsibly for lots of their key architectural decisions, several of which were behind the inability of people generally to use the site.  During a curtailed interview he continued to champion the approaches they had taken, which had failed, and even managed to support and promote the business model for Boo.com which had managed to burn through lottery winning cash in an amazingly short period of time (one founder entertainingly stated that they were 'too visionary', nope it was a bad idea, badly implemented).  People like this must be quickly exited from the programme as if they can't see any issues then they will be unable to fix them.


Responsibility with Action
What we haven't really seen so far is someone take responsibility with action in this crisis.  Sure the News of the World has been closed down but allegations by Jude Law against the Sun have been met with abuse rather than a culture of 'we are pretty sure we didn't, we take these allegations seriously, will will investigate and we are confident we will prove our innocence'.  The closure itself was simply an acceleration of a previously announced policy so there really hasn't been that active leadership yet in cleaning things up.

Responsibility with action in an IT failure is the person who stands up and says 'mistakes have been made, right lets fix them' and sets about driving change and leading the cultural shift that is normally required to recover a failed or failing project.  Responsibility with action is normally a quiet thing rather than a shouty thing,  its something that is done rather than talked about.  It isn't a committee to investigate  its an active approach to finding what went wrong and fixing it as quickly as possible.

Critically its not about blame in the sense of finding people to blame, its about finding problems and when these problems turn out to be people then those people are given the simple choice: change or leave.  It is about finding people who should have taken personal responsibility and ensuring that next time they do.

Recovering projects is normally one of the most thankless tasks that I do.  You enter into a scenario where someone else has screwed up and your end result is getting the project to a place where it should have been ages ago.  There is however something personally rewarding in changing the culture of individuals so that they are able to recognised the mistakes that were made and in exiting the toxic people from the process.  Crucially however there is one lesson that I've learnt doing this and that is that the first stage has to be recognise that there are systemic problems that need to be fixed.  If it turns out that actually its a localised issue then this is great, but the assumption must be that the rot is much broader and more general than the currently surfaced failure.  Normally there is a culture of poor sponsorship, leadership, management and clarity that leads to a general case of fail in which only the scale of the project fail stands out.

If you do see a project failing the first thing your should identify is not what went wrong in the weeds but how the sponsors and leaders will react.  Will they behave like a Brooks and deny everything?  Like a Cameron and take 'full responsibility' but actually blame farm?  Will they deny that there actually is an issue like McMullen? Will they fall on their sword and leave a vacuum or do you have someone with whom you can actually work to drive through the recovery?  Clarifying this 'top-cover' challenge is the first step in recovery,

Remember: Don't just people on whether they say they take or have responsibility but on what they do
 

Technorati Tags: SOA, Service Architecture

Microsoft's Eastern Front: the iPad and mobility

For those who study European Wars the decision to invade Russia consistently stands as one of the dumbest that any individual can attempt. Not because Russia as an army was consistently brilliant or strong but because the Russian country is just too big and the winters too harsh to defeat via an invasion.

For years this has been the challenge of those taking on Microsoft, they've attacked the desktop market. Created products to compete with the profit factories that are Windows and Office, even giving them away in the case of Open Office, but the end result was the same... Microsoft remained the massively dominant player. Even when Linux looked like winning on Netbooks the shear size and power of the Microsoft marketplace ensured that there would be no desktop victories. Sure Apple has leveraged the iPod and iPhone to drive some more Mac sales but the dent has been minor.

From one perspective Microsoft has also been the biggest investor on another front, the front of mobile and mobility, billions upon billions have been poured into the various incarnations of Windows on Mobile devices, from Tablets and WindowsCE to the new Windows 7 Mobile it has consistently been a massive set of money for a very, very small slice of the pie. This disappointed people who invested in Microsoft but as long as the profit factories were safe then all was fine.

I think however that this failure is about to really hurt Microsoft. Today I'm sitting in a train carriage (treating myself by going First, on my own cost) and there are now 7 iPads open and 2 laptops (of which one is mine), I'm using my Laptop as I'm creating PPTs but if I wasn't I'd be on the iPad too.

The fact that I'm on a Mac is irrelevant, the key fact is that after Neil Ward-Dutton asked if the stats were good I took a walk down the carriages and found that a 3:1 iPad/slab to laptop continued through-out first class and dropped to 1:1 in standard class. So in the "best" case scenario you had 50% of people using and working on iPads (or equivalents) and in the management section is was at 75% iPad domination.

These people are emailing, browsing, creating documents and generally getting on with mobility working. That is a massive shift in 2 years. 2 years ago it would have been laptops out and people using 3G cards or working offline, now its all about mobility working. This represents a whole new attack on Microsoft's profit factories and one from a completely different direction than they are used to. With rumours saying that Windows 8 for slabs not being available until late 2012 or even early 2013 this means that a full desktop/laptop refresh cycle will have gone through before Microsoft can hope to start competing in this space.

I'm normally asked a couple of times on this 5 hour train journey about my ZAGGmate keyboard for iPad and where I got it from with people saying "that is really good, I could ditch my laptop with that". This concept of mobility extends to how you use things like email. Sure Outlook is a nice rich Email client, but the client on the iPad is pretty good and has the advantage that you don't have to VPN into a corporate environment but just use the mobile Exchange (an MS product) connection so mobile signal quality doesn't impact you as much. As an example, on this trip I've had to re-authenticate on VPN about 12 times, normally with the iPad I of course don't have to do it once.

Its hard to not feel that while MS has invested billions in eastern front of mobility that in reality its left with no actual defences, a Maginot Line if you will which has now been roundly avoided by a whole new set of technologies which are not competing with Microsoft in the way they expected.

How long can the profit factories be considered safe? With 1% of all browsing traffic already from the iPad and mobility being the new normal its a brave person who feels that another 12 or 18 months won't deliver long term damage to Microsoft's core profits.

Technorati Tags: SOA, Service Architecture

The IT department - first against the wall when the revolution comes

I had a thought today, what with all the SaaS stuff out there and the increasing technical proficiency of new users, who often out-strip their internal IT departments in how they use and apply technologies. Is there a point to an IT department?

What is IT? "Information Technology" is the term but the reality is that when we say IT we mean the "internal development of technology". This department made a lot of sense when IT consisted of a lot of arcane programming and complex networking, in a world where no-one understood what "integration" really meant or why it was important for transactions to be atomic and for people to understand what two phase commit actually meant.

But does that world exist anymore? In particular I mean is there a point to having a great big IT department with IT management and Enterprise Architecture in a world where businesses change and where technology is an integral part of any modern business strategy in the same way as staff are. Has anyone heard of an "HR Project Manager" who organises the resources for a project? I certainly haven't, I've heard of HR admin or support for a project but the project management is left to the leader of the project. Why isn't IT going that way?

We have cloud computing, SaaS and all these other bits so doesn't that mean that with Mashups and the like that the IT department of the past is doomed?

Now this should be where I say "no" and then explain why, but instead I'm going to say "yes".

You see when I go into most IT departments they are mainly self-sustaining beasts, they have philosophies and leadership all of their own and more often than not have a CIO who is as close to the leading edge of technology trends as the CFO they work for. The IT department drives customisations, by providing the ability for the business to do it without the explanation as to why they shouldn't. The IT managers and IT project managers are often so fixed on a particular technology that they are an active barrier to the company changing its approach.

Its the IT department and its holistic henchmen of Enterprise Architecture who provide the barriers to cloud adoption and who promote the use of internal solutions, solutions they control and customise, over external provision. As the business starts to take control of business architecture and lay out the financial model for IT rather than simply a wish list of requirements its hard to see what the point of traditional project managers or enterprise architects is in this new world. Particularly in a new world where the business can just look at a SaaS solution and say "yup, that'll do" rather than complete a long project of customisation and installation.

As infrastructure becomes completely virtual the need for "experts" who can buy and install "the right server" disappears.

So what is required in future IT, is there any need for IT professionals? Well yes of course there is for several reasons

1) Everything will never come in a package
2) You'll aways need to integrate stuff

The key point is that differentiation is what IT people should focus on and start handing over responsibility for the commodity stuff to the business departments that use them. Finance should take control of the finance packages, HR should run the HR packages both as integral parts of their business. Sales should take control of their CRM and marketing packages. This switch of control would help accelerate the move to SaaS and away from customised solutions where they don't add value.

I'm not arguing here for a decentralised IT department, I'm arguing for the externalisation of IT and its management by the business and not by IT professionals.Yes sometimes the IT department helps drive the change, but very rarely from what I've seen, as the business becomes more tech-savvy than the old school tech managers its time for the business to take control back.

So what is left in IT? Well for me its the bits of IT that really add the value, the bits genuinely concentrating on where the business sees potential for ROI. In other words its the solution folks in IT, the real technologists who pull together various pieces and add a touch of development to create something that really differentiates the company. I'd guess this would be less than 20% of IT spend today, so my proposal is simple.

So what does that really mean? Well it means that current IT back office systems are really going the way of networks, mobile phones, land-lines and the like and moving out of technology and into procurement. In future the business will procure SaaS for back-office rather than ask IT departments to deliver it. The old IT department will be left doing "just" the differentiating parts.

So in other words the end result of this revolution is going to be that IT spend is split between procurement of services via normal business challenges and the commissioning of differentiating services. This should mean that the IT department is more about custom build than about package delivery, which is a marked difference over today.

So yes the current IT department is going away, but its replacement is going to be focused on smaller and more specific areas of the business and focused where innovation delivers actual value. This is not something that most IT departments will be happy with as it commoditises much of their current work. This is why in the coming change there will be many IT departments where the change will be extremely traumatic.

I firmly believe this change will happen and that traditional IT departments will be the biggest barrier in their inability to recognised the difference between business value and IT cost.

So will you be first against the wall when the revolution comes?

Technorati Tags: SOA, Service Architecture

There is no HR/Business divide, which is why its IT's fault

The IT/Business divide is something that exists in most businesses I've worked with. I think it comes from a few different drivers, one of which being that IT is often the smartest set of folks in the room academically if not socially. But one piece I can't agree with is that the fault for the divide lies on both sides.

Lets flip away from IT for a moment and concentrate on other "support" parts of the organisation. HR and Finance. These aren't the front-line of the business but they are critical support functions. Now I've regularly heard people in the business moan about Finance being too conservative or too controlling but I've never heard people talk about a Finance/Business divide or that the CFO is disconnected from the business. The perspective might be that Finance has a different view on the current opportunities or issues but not that the business and Finance are disconnected. HR even more so, the HR Director who is disconnected from their business is a fired HR director.

In IT however I've regularly seen CIOs who are disconnected from the business and seen architecture communities who have said classic phrases like "it doesn't matter what the business wants, if we say its not going in, its not going in". IT continues to talk technology rather than business and optimise things (programming languages) that add zero business benefits. IT regularly bleats "The business must realise how important this is" rather than actually working out what is important to the business.

The business/IT divide is the fault of IT because IT doesn't make the effort to communicate the value in the language of the business its like the worst kind of tourist who thinks that shouting louder is better than learning the local language.

Its time for IT to stop looking inwards on optimising wheels and start focusing on how to communicate about IT with the business in their own language.

Technorati Tags: SOA, Service Architecture

Social Business when does it pop?

Okay so LinkedIn is leading the social business IPO charge with various numbers being touted as a valuation from its current off market evaluation of $2.5bn (on $161m revenues and $10m profit in 9 months) to the proposed IPO. Revenue is more than doubling over 2009, but costs are nearly matching the same level of growth which delivers the minimal actual profit. The forecast isn't exactly huge either with them predicting slow downs, not this could be CYA words but there are some good points in there.

So what would $2.5bn as a valuation make LinkedIn equivalent to in the "real world"? Well how about Easyjet? Easyjet are a low cost airline who are part of the revolution in the cost of short haul travel in europe.

Assuming LinkedIn's profit/revenue growth continues then lets say we get $210m revenue and $15m profit. So how does Easyjet stack up? Well from one perspective not well.

Revenue at EasyJet was £2.97bn so almost 40 times (1.6x $) , Profit was £121.3m or about 12x (EBITA is £274m). So bang for buck is arguably better with LinkedIn but what does this profitability mean for EasyJet's valuation? £1.7bn which is about $2.7bn or probably less than LinkedIn will IPO for.

Ah but LinkedIn has 90m users, although few use it regularly and some accounts might be duplicates... as opposed to Easyjet who have "only" 50m passengers per year.

Now there are lots of other bits that drive valuations but haven't we seen this before in terms of massive valuations for companies where profitability was a secondary element? I like LinkedIn, I use LinkedIn and I wish them all the luck in the world. I can even see their business model around job hunting and head hunting making a lot of sense and them really getting a decent set of revenue from it.

But are they worth the same as a well run and profitable airline? The answer is of course that they are worth what people will pay for them which means invest at the start of the bubble but don't forget that its a bubble.

Technorati Tags: SOA, Service Architecture

Data Services are bogus, Information services are real

One of the questions that used to be asked, or proposed as fact, in old school SOA was the idea of "Data Services" these were effectively CRUD wrappers on Database tables and the idea was that they were reusable across the enterprise. I've said many times this is a dumb idea as the importance is actually about the information, which means context and governance.

Now the other day when I was talking about MDM a bright spark pointed out that I hated data services but wasn't MDM just about data services?

Its a good challenge, mainly because that is the problem about how many people view MDM. MDM is, when done well is about the M and the M not the D, i.e. its more about Mastery and Management than it is simply about Data. What does that mean?

Well lets take everybody's favourite MDM example "Customer" a Data driven approach would give us a Service of

Service Customer

• Capability: Create
• Capability: Update
• Capability: Delete
• Capability: Read

Now this is the "D" approach to MDM and SOA, also known as the Dunce's approach, its about Data Services and viewing the world as a set of data objects.

The smart approach is to view MDM as an information challenge and delivering information services so instead of the data centric approach we get

Service Customer

• Capability: Establish Prospect
• Capability: Establish Customer
• Capability: Modify
• Capability: Change Status
• Capability: Find
• Capability: Archive Customer
• Capability: Validate Customer
• Capability: Merge Customers
• Capability: Split Customer

Here we start exposing the customer service and make clear two things

1. We are talking about the customer in context
2. We reserve the right to say "no" to a request

So this is where customer genuinely can be used from a single service across the enterprise. This service takes on the responsibility to authorise the customer, or at least ensure that authorisation is done, it sets the quality standards and governance standards and doesn't allow people to do what ever they want with it. It includes the MDM processes elements around customer management and provides a standardised way of managing a customer through its lifecycle.

This is fundamentally the difference between a business SOA driven approach which concentrates on the services in their business context and with their business governance and a technical driven approach which looks to expose technical elements as via a technical wrapper.

Technorati Tags: SOA, Service Architecture

Rightscale - cloud provision as a commodity

I made a comment about cloud providers not being good long term investments well having a drink with Simon Plant of Rightscale it became clear that actually its already pretty much a cooked goose in the cloud space. Rightscale do the VM creation and provisioning stuff across most of the public cloud providers as well as folks like VM in the "private" cloud space. What does this mean?

Well simply put it means that you can have Rightscale create the VM image for you in a way that means you can deploy it to pretty much any cloud you want. This means you can start doing SLA/price arbitrage across providers and reduce any potential lock-in from the cloud provider. I like to think of this as an "iPhone strategy" as before the iPhone it was the carrier who would specify what the phones did and would put network specific cruft on them. Apple came along with the iPhone and said "nope, our phone, exactly the same, every network, managed by us", Rightscale is effectively the iPhone and iTunes for your cloud provisioning. By using an intermediary approach you get to control not just the standard stuff like number of VMs, CPUs, Storage etc but the more important stuff like which actual cloud you are deploying to. If you want to shift it in-house from an external provider then you can, if you want to shift between providers then you can, and if you want to start off internally and shift it externally when demand spikes or when it makes financial or security sense then you can.

So Rightscale are doing to clouds what clouds have done for tin... commoditising them. This means cloud providers are in a volume business with retail style metrics and margins. Effectively this means that Rightscale are achieving commercially what Open Cloud has so far failed to do publicly.

So in the same way as you wouldn't consider an Intel/AMD box where your software could only ever run on Dell (for example) why choose an approach to clouds that means you can only choose one provider?


Oh and I bought the drinks BTW.

Technorati Tags: SOA, Service Architecture