Agility, service levels, and cost

06.10.2011 by Martin Kuppinger

Some two weeks ago I’ve been at the EMC EMEA Analyst Summit in France. In one of the session Chuck Hollis, VP Global Marketing CTO of EMC Corporation (what a title, isn’t it?) made a very good comment when of the presenters talked about the needs for

  • agility and speed
  • service level fulfillment and improvement
  • cost optimization

of IT when providing services. He pointed out that IT looks at this typically in the order of cost – service level – agility, while business looks at agility – service level – cost. I really like that.

You might argue that business always is talking about IT being too expensive. Yes, they do. But there are reasons for that. On reason is that business still frequently doesn’t really has an answer on the “what’s in for me?” question. If business doesn’t see a value (and supporting the need for agility, e.g. enabling business to become better, is sort of the big theme behind the business value) it looks at costs. No surprise at all. However, if IT provides what business really wants, then the discussion is much less about cost.

With other words: IT has to understand what business really needs. Look at the business services they want, at the business value, and how IT supports agility and speed. Ensure the service levels. And then try to do it at optimized cost.

Honestly: That isn’t a groundbreaking insight. Many of us are talking about this since years. But do we act accordingly? Not always. Always having in mind that the order better should be agility – service level – cost than the other way round might help us to become better in Business/IT alignment.


Critical success factors for IAM projects

13.07.2011 by Martin Kuppinger

This is sort of a “back to the roots” post, but for some good reason. I’ve done several advisories and customer calls recently, and in some of them it became obviuos that companies tend to miss some of the critical success factors for IAM (Identity and Access Management). Some of the projects are still too technology-focused. So I’ve put together some key success factors for IAM projects. These are not that technical, so you won’t read things like “support the cloud”, because that should just be a result of the requirements analysis.

Requirements: Understand the requirements of Business and IT – of both! And look at what might become requirements soon, so the obvious trends (like Cloud Computing, like the increasing regulatory compliance pressure even in not-that-heavily regulated industries). Knowing the requirements helps in defining the right architecture and in slicing the big elephant of IAM into smaller pieces, e.g. projects you can handle successfully.

Architecture: IAM is more than only provisioning, even while provisioning still is an important element. But oeverall, architectures are increasingly modular, providing more flexibility, better integration with other pieces of IT, and the ability to serve new requirements quickly when needed. So, look at the architectural options you have today and don’t focus on the classical architectures only.

Context: IAM is one element of IT, and one piece of your Information Security framework. It has to interface with Service Management and with other Information Security technologies, as well as with the entire GRC (Governance, Risk Management, Compliance) stack. So don’t look at IAM without understanding how it fits into the big picture.

Policies, Processes, Roles: Does your organization have well-defined policies for IAM? Does it have well-defined processes? And how about business roles, defined by the business? If any of these elements is missing, important input for your IAM deployment is missing. The policies define what you have to do and what to do first, the processes are about your implementation of provisioning and Access Governance (and more) – not even to speak about roles. The good news is that businesses better understand the need for these and are more willing to actively work on these topics then some years before.

Team: For sure it is always about having the right people – the ones who understand technology, the ones who understand business, and the ones who connect both sides.

Service focus: Last but not least it is about having a service focus. IAM is one service IT provides, as part of Information Security. It has to be user-centric, focusing on the services the users (from business and IT) require. That includes integration points to your service management environment.

You might define other ones – but these are the ones I find most important from my experience.


Why you should focus on the infrastructure layer

21.04.2011 by Martin Kuppinger

In these days of slowly increasing maturity of Cloud Computing it becomes more and more obvious that and why IT depends on a well thought layer which I tend to simply call “infrastructure”. I have two simple pictures of IT in mind:

  • The somewhat classical model of platform, infrastructure, and software, like found in PaaS, IaaS, and SaaS in the common Cloud Computing meta models. It’s about hardware and other foundational components like operating systems, about the layer between to manage and orchestrate everything, and the applications themselves.
  • Another view consists as well of three layers. The services exposed to the users (i.e. in most cases the business) on top, the service production (either in the public cloud or a private cloud or in non-cloudified IT environments) at the bottom – and a layer in between which again is used for managing and orchestrating everything. Again, this layer might best be called “infrastructure”.

This layer is which connects everything. Thus, efficiency and effectivity of this layers are the foundation of efficiency and effectivity of the entire IT. Optimizing this layer allows to better connect the available services to the business demands. It allows to manage the different layers in the cloud.

When looking at that layer, there are some few key elements:

  • Service Management, e.g. the entire area of procurement, service request management, accounting, availability, performance, and whatever it requires to ensure that the services are delivered as expected
  • Information Security Management, including IAM (Identity and Access Management) and at least IT GRC (Governance, Risk Management, Compliance)
  • Application Infrastructures, e.g. middleware allowing to connect services, to enhance them if required and to do the orchestration

Did I miss important elements? OK, there is the classical IT security, however that’s part of Information Security – the reason we are looking at IT security is to protect information. You might add some other elements, however I tend to keep this model simple.

To me it appears to be more important to look at the dependencies of the three services. Information Security and Service Management have to work hand in hand, to ensure that access to services is restricted and controlled. Applications and Information Security are tightly related – think about how to build secure apps. And applications are, at the end of the day, nothing else than services which have to be managed.

I personally believe that starting with such a model and outlining the blueprint for your future IT definitely helps in separating the important from the less important things and to focus on building an IT ecosystem in your organization which is stable and works with whatever you plan to do in the Cloud.

See you at EIC 2011 in Munich, May 10th to 13th.


From technology to business – the shift in Identity and Access Management

10.02.2011 by Martin Kuppinger

Being involved in a lot of advisory projects at end user organizations for some years now, I’d like to share some of the fundamental changes I observe. There is always a gap between what analysts like us, KuppingerCole, predict and what is done in reality. Thus it is always great to observe that things we’ve predicted and proposed are becoming reality. So what has changed over the course of the last years – trends becoming reality:

  • Access and Identity Management: Back in 2008, I’ve blogged about the relation of the terms “access” and “identity”, the latter being much more difficult to explain. Today, the clear focus is on access controls, they are in focus.
  • More flexible architectures: Some time ago, the idea was to have one provisioning system which covers all. Today more flexible architectures like described in one of my research notes become reality. Access Governance on top of several provisioning system allowing to protect existing investments and to move forward in smaller steps are increasingly common – and the increased maturity of Access Governance tools is the foundation to do this. Provisioning is increasingly seen as a technology layer below such integration layers (not necessarily Access Governance). And so on…
  • Access Governance on top, doing things more business centric: A consequence of this is that companies focus much more on the business user and their requests for access (yes, for access, not mainly for identities). This isn’t entirely new but the way IT interacts with business has changed over time.
  • Integration with service request approaches (not service desk, like BMC believes): Another tendency is to integrate access and identity requests with other service requests, either in the IAM/Access Governance tools (like in Quest One ActiveEntry or through Avatier AIMS, to name just two) or in service catalogs. However the interface has to be fore business users, not the IT – e.g. not the service desk itself. Service desks are as well increasingly part of the integration, within the more distributed architectures mentioned above, but for the manual part of fulfillment in systems which aren’t connected through a provisioning system.
  • Bodies of rules, policies,…: The, from my perspective, most important change is that more and more projects start with the definition of  “bodies of rules”, policies, concepts – and not with the selection of a technology. That definitely makes sense: You don’t start building a house by buying stones, you start with blueprints.

Two more (amongst others) trends increasingly becoming reality are

  • Externalization of security out of applications in a standardized way, based on XACML and other approaches (and yes, there are real world projects out there on this)
  • Hybrid cloud IAM and Access Governance – how to deal with mixed environments

Overall there is a clear shift of how IAM is done. And this change will continue, with the upcoming integration of Access Governance and other IT GRC approaches into enterprise-wide GRC concepts.

To learn more about the trends as well as the best practices don’t miss EIC 2011, where thought leadership and best practices come together.


Cloud Computing is mainly Service Management

28.10.2010 by Martin Kuppinger

When looking at all the discussions around the “cloud” I still miss some focus on the real essentials of a strategic (!) approach for using clouds. Clouds are, when looking at the right now common understanding of private, hybrid, and public clouds, in fact nothing else than IT environments which produce IT services. These services are provided at many different layers, like in the common (and pretty coarse grain) segmentation into SaaS, PaaS, and IaaS. But: It is about the (efficient, scalable,…) production of standardized, reusable services.

Cloud Computing is about using these services. It is about procurement, management, orchestration, accounting, and so on. With other words: Cloud Computing is mainly about service management, in a standardized way. In a perfect world, all services of all products (internal and external) would be managed consistently. There could be one consistent accounting, ending up with something like an ERP for IT. However, the service management aspect of Cloud Computing appears not to be in the centre of most discussions around Cloud Computing. Many discussions are just about tactical comparisons and views of parts of Cloud Computing. Many discussions are around security. But about service management, the really strategic thing? The part which will fundamentally change the way we are doing IT?

For sure there is a lot of discussion around service management today. ITIL is a good example. However, that covers just a part of IT. We have to look at it from the highest layer (business and its requirements, described as real business services like “managing contracts of type … in compliance with regulations and…”) down to granular web services used in SOA architectures. Services are sort of everywhere. And the future of IT is about having two layers:

  • Service production (In the Clouds)
  • Service consumption (Cloud Computing)

That requires fundamental changes in IT organizations. The core competency is to become best in class in mapping business requirements to the required services, e.g. in doing the “cloud computing” part right. For the “production” part of IT, it is about becoming best in class in providing efficient services. But typical IT organizations will be split into two parts: Consumption/Orchestration/Management and so on – and production in the private cloud environment. Enabling this shift is the key issue for any organization today.

You might now argue “what about security?”. Pretty easy: Security is a part of this. Every service has a functional part and a “governance” part: Where is the service allowed to run due to compliance? What about encryption of transport and data? Who is allowed to access the service (or parts of it)? And so on… With other words: When you’ve solved the service management piece, you’ve automatically solved at least a large portion of the security piece. You might argue that there are some infrastructural aspects not covered by this (how to enforce what you need for service governance). But that could be understood as well as part of your service environment.

A lot of aspects around Clouds, Cloud Computing, Cloud and Services, Cloud Security and so on will be discussed at EIC 2011/Cloud 2011 in Munich, May 10th to 13th.


Why Software Security is a part of any Business Model

19.05.2010 by Martin Kuppinger

During the last weeks, with all the discussions about security- and privacy-related issues in social networks like Facebook or SchülerVZ, I’ve had some talks with people. My position is that these issues are a result of bad software architecture. The counter argument sometimes has been that when building these networks the focus has been on functionality, not security – and that the business model of these networks is based on the functionality. What was meant by that is that you should first care about functionality and that security is somewhat irrelevant because it doesn’t help you in achieving your business goals.

However, that is fundamentally wrong. The current issues prove that the business model of these social networks is threatened by security weaknesses. They also prove (like any good software architect knows) that it is virtually impossible to add good security afterwards. You have to build it in from the very beginning. Trying to fix issues by blacklists or whitelists or by adding some URL obsfucation or something like that always will address symptoms, not the cause.

What we currently observe at many social networks and eCommerce sites is that there is more attention on security and privacy issues – and the providers are struggling with this because their software security architecture doesn’t allow to flexibly react on this. For sure some of these providers are somewhat reluctant in changing their privacy and security settings because their model relies on “openness”. Anyhow, even Facebook has had to make changes, and that will continue.

Good software security architecture would allow these providers to just change some settings by configuration. That would be easy and not very expensive if the software were well constructed, with security in mind from the beginning. That includes the ability to flexibly use different authentication mechanisms and a consistent authorization model which is configurable. For sure there is some more work to do in architecting and developing such a system – but it is significantly less work than trying to fix problems afterwards (and, besides this, doing it from the beginning is a solution and not a patch which leads to patchwork with security and privacy holes).

However, the most important lesson one can learn from that situation is that software security is relevant to any business model. If it inhibits growth, if it leads to a loss of trust and in consequence of users then it affects the business. The  argument that it is first about time-to-market isn’t really valid. It doesn’t take much more time and efforts to do software security right then to ignore this – especially because some security always has to be added before releasing a software. The real valid rule is: You always will pay for bad software architecture. And you will pay for bad software security architecture. That is like in real life architecture and construction – go back to the bible, even there it is told that you shouldn’t build your house on sand. Ignoring software security at the beginning is nothing else than building houses on sand. And a good business model which thinks strategic doesn’t ignore that fact.

Building software without a good software architecture is sort of building a car without breaks. You can argue that the car is for driving, not breaking. And you can argue that it is about functionality not security. But would you trust in a car without breaks?


What business has to learn so that IT can align

26.02.2010 by Martin Kuppinger

We’re talking a lot about the need for IT to align with business. But it’s not about a one way road. There is no doubt that IT has to think much more “business”. Risk focus (here and here), performance management, the understanding of IT as Information Technology instead of Information Technology, the path towards an ERP for IT,… I think that many CIOs and CISOs are well aware of this and many of them are working towards that goal.

However, if I look at the business side, it appears to me that IT still is somewhat ignored when it is about alignment. Two examples out of many from my practice:

  • When talking about GRC initiatives at the IT level, customers frequently complain about risk management initiatives with focus on organizational risks where they are not even able to start a discussion about integration. However, any IT risk is just a risk because its associated with organizational and (sometimes) strategic risk. Thus, you can’t ignore the IT risk perspective from an “Enterprise” GRC perspective (which, by the way, is sort of an arrogant term, ignoring exactly the fact I’m discussing here – “Business GRC” would be much more appropriate). You can’t run a business without IT. It’s part of the operations. And IT risks might have severe impact on your overall business performance – look at fraud in financial institutions, data theft, and so on.
  • When talking with the Business GRC vendors – look at the upper layer here – some of them (not all!!!) show an attitude of “we’re doing the relevant business GRC instead of the irrelevant IT things” and claim that they don’t need to provide integration or to support the IT part of the business.

However, given that IT is an important part of every business (the German Bafin – the government agency responsible of auditing and controlling the financial institutions – explicitly claims that IT is a core part of banking business and has to be understood that way), that means ignoring risks. And, even more, it means ignoring that there are elements in risk management which are provided by IT. You need automated controls besides the manual controls. And all the Business GRC tools are IT tools, by the way.

The problem from my perspective is that as well some vendors as many responsibles in the organizations don’t want to play with the IT guys. However, they could not only do a much better job by better executing their controls but they as well could do their job correctly, by really adressing the whole breadth of (operational and strategic) risks.

That’s just one example where business has to learn to better align with IT – and it’s not the only one. Look at the description of business services. For sure there has to be a translation into IT services at some point of time. But before you can do that, you have to have something which can be translated. And frequently, the problem isn’t the translation but what has to be translated. If the original text isn’t sufficient, the translation result never will be. Everyone dealing with software development probably has made this experience: Many issues in software development are caused by an insufficient descriptions of the requirements.

I think that it is time that not only IT understands that it exists only because it provides value to the business but that businesses rely on IT and thus have to align with IT. And that Business/IT alignment is definitely not only something where IT has to learn a lot. Businesses have to do as well – to understand the operational impact of IT (and IT risks), to describe their service requirements, to accept that the operational risk associated with an IT risk has to be balanced with the opportunities of a business service. Just think about all the insecure applications we have in organizations just because a department required them and IT security concerns have been ignored. That has not only been because IT wasn’t able to translate the IT risk into an operational risk – it has been as well because business didn’t understand IT.

Thus, both have to learn. And sometimes it appears to me that business has to learn even more than IT. Not only the people within organizations, but as well the consultants at the different levels. So if your consultant for risk management hasn’t yet covered the operational impact of IT risks and how to deal with that, you should ask him why – and if he doesn’t provide a valide answer, you should re-think the engagement…


The risk of costs

28.01.2010 by Martin Kuppinger

There is a constant pressure not only on IT but all areas of organizations to reduce costs. However, that frequently ends up with higher risks and potentially higher costs due to these risks. The problem is: Most organizations, especially in controlling and management, think much more about cost than risk. But cost savings (which are not necessarily negative) without a risk view are a risk – somewhat of a tautology, I know…

That is why Risk Management should be a standard and central element in management, as well for business as IT.

Read the rest of this entry »


From IT to Business

07.01.2009 by Martin Kuppinger

The topic of IT-Business Alignment isn’t really new. It is discussed for years right now. And several software vendors, mainly in the area of “Business Service Management” claim to solve the threats in that area. But, honestly: I believe that we are, in most cases, far from a real IT-Business Alignment. I have blogged several times around this, topic (here, here, here, and here).

But let’s start with my definition of what IT-Business Alignment is: IT does what the business requires – not more, not less. That includes aspects like the ability to efficiently respond on new business requests, the ability to report on and enforce business controls (including all the GRC requirements), and the efficiency of IT itself in the sense of a streamlined, lean IT organization.

There are, from my view, two main steps to go:

  1. Reorganize IT
  2. Implement a consistent control layer between Business and IT

From my perspective, the lessons we’ve learned from outsourcing and outtasking are a good basis for IT reorganization. Strategy has to be in-house – that is the core part of the IT department. Other parts might be done inhouse as well, but organized in own “centers” with clearly defined SLAs. An IT organization which consists of a strategy/architecture department for guidelines, a GRC department which focuses on all relevant controls, and some decentralized IT knowledge in business organizations (define the requirements for applications and other IT services) might be the lean approach. That requires the competency for guidelines and strategies, including a strong influence on sourcing decisions. But IT itself would be pretty small. The “doing”, e.g. running systems can be done inhouse – there is no need to outsource this. But in that case, these are seperate departments which act, like described above, like external entities (or like the internal facility management or corporate security or any of these internal service providers).

The layer between IT and Business is, from my perspective, an GRC layer which goes well beyond Identity and Access Management related GRC approaches and well beyond BSM/ITSM, providing a consistent framework for business controls for IT.

For sure we can’t change an organization immediately. There are several prerequisites:

  1. The CIO role has to change, clearly focusing on that IT-Business Alignment, with the responsibility for GRC as main task.
  2. You will need architects and strategists for the central department.
  3. You will need persons with a good IT understanding in the business departments.
  4. You will need managers which can really manage the IT “centers” as business managers.
  5. GRC tools have to go beyond just IAM or BSM support, moving towards real platforms.

Thus it is a long way to go. But I strongly believe that we have to go that path, for more efficient organizations and to reach the target of IT-Business alignment.


Services
© 2014 Martin Kuppinger, KuppingerCole