Cloud Services – the Business perspective

Cloud Services have rushed into the markets relatively rapidly. It’s only been a little more than 10 years ago when we first learnt about the cloud computing.

Cloud computing – where do we stand today?

Last year
(2016) the Cloud computing revenues jumped 25%, and the year 2016 was the first in which cloud computing started to dominate many IT market segments according to GeekWire’s article. In addition to that, Operator and vendor revenue for six segments of cloud computing reached $148 billion during that period, so it’s safe to say Cloud computing is totally mainstream today.

Operator and vendor revenue for six segments of cloud computing reached $148 billion

We all know the recent history of data centers emerging and customers buying monthly-basis fixed priced data computing volume, in volumes. Some customers even ended up building their own data centers instead of using the IT providers’ data centers.


 Cloud computing vs. Data Centers

Today there’s an ongoing battle between the Cloud computing vs. Data Centers. I’ve seen many articles addressing the issue, for example Atlantech’s blog has a pretty good, albeit short, comparison between the Private Cloud and Data Center, written by Tom Collins (any relationships between him and the famous cocktail drink are unknown to me! :) )

Cloud Services – the Business perspective

Having said that, I just can’t get over it, that in my opinion most of the above mentioned comparisons seem to lack something. Yes sir/ma’am, you’ve got a number of rows of text explaining the difference between the choices, and features are been unwrapped in tiniest details. But often these comparisons lack the true Business perspective of Cloud computing! Instead of listing the features and differences, one should try to see the world through the customers’, the business’ point of view. And that’s where I’m putting my 20 cents now.

these comparisons lack the true Business perspective of Cloud computing

The business is just so easy: buy low, sell high. Or, produce something (goods, services, whatever) people desperately want or need. The key question is: How can Cloud computing help make me more successful in my business operations?

Business wants answers to the right questions

What the business really needs is for example:

  • Cost efficiency: Business is willing to pay, but only for the time period the business requires, and only the required amount (+ perhaps a little bit more than that, just in case) of services, like computing power, storage, network connections etc.
  • Just in time: Business needs the services right on time! Not two months ahead and most certainly not two weeks, let alone months, too late.
  • Easy buying: transparent pricing, klick-to-buy (limited amount of ready-made choices or _very_ user-friendly configurator tool).
  • Scalability: during the night-time there is might be less usage than during the daytime, and when getting a number of new users to the system, it should be possible scale the platform up very easily.
  • Continual improvement and development: there should be tools available to support the r&d of the system, when necessary.


These are only a few key factors that the business is looking after when thinking about Cloud computing. Of course there are other factors as well, like user accessibility, security issues, multi-site data replication and so on.

Oh yes, the recommendations!

Now, I never do this, I have never done that before – but I’m about to do it. Do what? Give recommendation! And guess what? I’m going to recommend the Cloud services of my employer, Fujitsu Ltd! This probably ruins my credibility, but as of today, 2nd of February 2017, I’m confident that Fujitsu’s Enterprise Cloud Service K5 is the best Cloud based solution available in the world! Simple as that.

Hyping up the K5 – seriously

No, I’m not getting paid for advertising my employer’s stuff. I just stand behind my opinion, that the Fujitsu K5 meets all the Business requirements I listed above: thoroughly transparent, hour-based pricing, getting the Cloud computing up’n’ running in a few minutes*, ready-made computing packages that are easy to configure, very good scalability options, supports OpenStack and offers an application execution environment service based on the open source Cloud Foundry.

* Means that if you want to run the K5 Cloud in parallel or as part of your own data center’s internal network, then of course it takes more time than a few minutes, but it’s also up to other actors than the K5 itself.

Imagine what you can do, if you are developing software on open source tools, use PostgreSQL, and would like to pay for only the amount of computing power and storage you really need, for only the time-period you need. In K5 you can find support for your sw development and DevOps, yet there’s support for OpenStack, VMWare and Bare Metal. So it’s fare to say you really got options.

Imagine what you can do

Of course it’s not always possible to do that, as quite many enterprises are using Oracle of Microsoft databases and end up paying for millions of €uros to these bloodsuckers I mean distinguished IT companies yearly. Sometimes it might make sense to start thinking of converting the databases towards more cost efficient db solutions.

It’s about a time to change. Why not?

Personally I have, from time to time, given a thought to why do so many enterprises really pay carriages of money to these distinguished IT companies. I’ve only figured out two reasons:

  • “We have always done that” -> that is of course the most rock solid explanation. Why change anything, ever?
  • “No one has ever got fired for recommending IBM” -> this was the key guideline to all the investment bankers during the ‘70s and ‘80s, and is still occasionally a good emergency fake.

To the end I’d say: take a chance! If not anything else, you might find yourself saving loads of money in terms of licence costs.

Pictures are from Pixabay.

License Management – trick or treat?

Sailing through the murky waters of License Management can be frustrating. I’ll share some ideas and pitfalls I’ve gone through with the topic in question, and I’ll make one suggestion which would help people dealing with License Management issues.

That was then…

Once upon a time there was a customer who needed certain software to run his/her business. Back in time everything was relatively easy: customer bought a software (application), which was delivered on a media like 5.25” or 3.5” floppy disk. Customer used the software as long as it was needed and later on bought perhaps a new application.

In case there was no proper software available, customer most probably contacted a software company to help specify the requirements and develop the software in question.

Plain and simple, neat and tidy. Development of hardware was so rapid that one didn’t usually reach a new version of the software until his/her workstation was already outdated.

floppy-disk-214975_640At that time, if there was need to run the software on more than one workstation either you bought another piece of the same software or (probably) violated copyrights by installing the software into a new workstation. But who was ever going to know about that, as your workstations were not networked?

Somebody then came with the idea of licensing: why to demand customers buy yet another copy of the same software, when you could just sell a ”licence” (for example a string of letters and numbers) and grant customer install the software to n pcs of different workstations?

Around the same time more and more workstations joined the network called the Internet and the first concurrent user licenses appeared to the market.

…this is now!

Nowadays it’s a jungle out there! As long as you have a small business with <5 workstations and less than 10 applications you’re doing OK. But once you run even a little bit bigger business – not to mention global scale enterprises, it’s a whole different story.

Let’s dig a little bit deeper into the world of licenses.

Licensing models

Let’s assume you are a CIO in a global scale company and it’s in your best interests to grab the best license agreement with your software vendor(s).

  • ”What should I do?”, you may ask.

Well, I have a rock solid answer that usually works: go to the basics. You should first define and specify certain basic information about the usage of the software you’re about to buy licenses for. Start with i.e. something like that:

  • amount of total users
  • amount of concurrent users
  • geographical locations of your users
  • number of servers
  • number of processors in servers running the software
  • number of cores in processors in servers running the software
  • pretty much anything, all the available information!


Number of total users is often used as a pricing basis, but there may be other situation factors as well.

Concurrent user licenses

You have operations, say, in Australia, Poland and Argentina. Your total number of users for this particular software is 9000 users. But the user base is split between the three office sites in different countries, different continents. In this case you should find out if you could agree on paying only for the concurrent users and actually save money by buying software license for 3000 concurrent users instead of 9000 total users.

Concurrent user licensing is relatively fair model of pricing the licenses. The downside is it often requires almost continuous network access. Normally it’s not a problem, but in certain field services –based work it can still be an issue today. The licensing service, which lies on a license server pings workstations at certain intervals to make sure there’s a license in place. It releases unused licenses from workstations and reserves licenses to workstations whenever needed. If you run out of licenses, you usually have to wait until someone stops using the software and the license is released into the license pool. Or you go out to buy some more concurrent user licenses.

Other licensing models

There’s a number of software where licencing costs are calculated regarding the environment they run. In other words you may need to report very detailed-level information describing your data center: number of servers (installed/using the software in question), number of processors (in the server that is running the software in question) and the number of processor cores (in the processors residing in your servers that have the software installed or are using it).

Now, I’m not going to go further into the world of different licencing models. But I want to make a question:

Why has license management been made so god damn difficult!?

It’s everything but straightforward to manage your licences. Buying can be relatively easy, if you have very deep pockets and you are willing to throw your money away. But buying just the licenses you need, for the time-period needed, and the correct amount of ’em.. you name it. It’s like a jungle out there.

 3rd parties showing up

There are companies performing license auditing in favor of the IPR owning companies. For example Microsoft performs – or their license auditing partner company does the job – a so-called ”true-up” auditing for an organization and then they report to Microsoft about the situation, and MS then tells the amount of needed new licences. In the world of volume licensing, true-up –stylish approach is quite good because the idea is that software can be installed wild and free, and then the auditing is conducted once a year to calculate the number of required new licenses. So one doesn’t necessarily need to purchase new licenses at the same time when installing new software, but accounts are being balanced annually.

 Sniffing through the environment

The auditing itself usually consists of investigating the environment. Normally the party that performs the check-up asks for certain figures (numbers of workstations, servers, cores etc.) and they often come up with a small software that sniffs through the agreed networks and creates a report regarding all the foundings (for example, databases).

Quite often the license auditing ends up with the software company presenting a bill to the customer and the customer usually doesn’t have any other choice but to pay the price, whatever it is.

Every license has its price tag

There is basically nothing wrong with this: if you want to use licensed software, you ought to pay for it. But..

..what bugs me in this scenario is the fact that customer pretty seldom has any real possibilities to question the calculations regarding the price tag. Unless customer happens to be one of the Fortune 500 companies or similar size, they don’t have a department filled with software license architects and lawyers.

Customer pretty seldom has any real possibilities to question the calculations regarding the price tag

So the set-up is often like a David and Goliath where David in fact has nothing to fight with. I’m not saying there shouldn’t be a price to be paid if you use licensed software, but the customer lacks the possibility to really check the calculations in many cases.

In addition to that, there are certain loopholes that make it possible to save some money in software licenses. For example, if a customer can prove that usage for certain software is intended to be only temporary, a very short time, or usage of the software differs somehow greatly from regular usage of the software, there might be a possibility to negotiate lower price for licenses under such use cases. However, there’s again need for department of software license architects and lawyers.

In my opinion, the ICT sector is clearly in need of actors working in favor of a customer! There should be consulting companies who take role for the customer regarding licences. These companies could provide end-to-end service for customer companies, all the way from designing and specifying the need for licenses (by evaluating the required platform solutions), then they could play the center role in purchasing required licenses, and yet they could be analysing and evaluating license auditing in favor of customer companies.

The ICT sector is clearly in need of actors working in favor of a customer

For sure, that wouldn’t be cheap. But then again, it’s very easy to waste money by buying i.e. enterprise licenses instead of standard licenses or too much licences ”just in case” etc.

If there were such actors, I’d definitely recommend using their services!

Yadda yadda

This must be – by far – the most hazy, fuzzy, unclear, inconsistent and frustrating blog text I’ve ever written. Partly because the License Management is very treacherous area and partly because I might have tried to swallow and elephant on one bite. I believe I’ll get back to this topic in the future with more specific approach to a limited section of world of License Management.

Pictures are from Pixabay.

DevOps – what and why?

Let’s talk about software and service design, development/engineering and maintaining.

Traditionally, software development has meant a team who first designs the software, then they give the specification to another team who does the hands-on programming and testing the software. These phases have been thought of being the ”project” state and the project manager has been doing his/her job using a waterfall project management approach: design – develop – release.

After releasing the software there’s usually been a supply team who takes care of the software and pretty much makes use of ITIL®’s Service Operations best practices. It’s also notable that the past waterfall-styled projects have often been pretty big in terms of the project scope.

Think about this: Wouldn’t it be good if your product or service would be developed in a controlled way, piece by piece and you could be certain your production and development do the things together, hand in hand?


Traditional moffice-875695_640odel of software project development has been widely critized for causing silos. Silos are the infamous grey area where responsibilities are unclear, often ending up in the situation where somebody didn’t do anything, because he/she/they thought that someone else did something and finally nobody did nothing.

In practice this means that a) when the Design team has finished the specifications, they don’t care about helping developers get into the speed, but they just hand out the specs pages and think their job is done. Then b) developers do the programming according to the specs and c) throw the release to the services team for support & maintenance. And then after a while there will be a new version ready for release and to be maintained.

Silos are the infamous grey area where responsibilities are unclear, often ending up in the situation where somebody didn’t do anything, because he/she/they thought that someone else did something and finally nobody did nothing.

Problems with silos

What if the specs are somehow inadequate? Coders code and the result is something else than it should have been? What if the production environment where the software is supposed to be run and maintained differs greatly from the test environment where the product was developed? Whose responsibility is to make sure these kind of issues won’t get in the way?

ITIL has addressed this dilemma at least a little bit. There are notions that Service Operations should be involved early in the process. For example in ITIL’s Service Transition life cycle, in transition planning and support there’s a question if the plans have been agreed and authorized by all relevant parties (customers, users, operations, and support staff)? The idea is clearly to get all the relevant parties – including naturally Service Operations people – involved early enough in the new/changing services.

But according to my experience ITIL doesn’t cover all the possible silos there are. I was once discussing with a Canadian guy who was the responsible for the project management department  in a big German-based transportation & logistics company and he told me he hates ITIL because in his opinion ITIL didn’t do anything good but was cannibalising the software projects.

I believe that’s true up to some point. Even though ITIL is not a project management method, it lacks a credible way of linking the project management and service management.

He told me he hates ITIL because in his opinion ITIL didn’t do anything good but was cannibalising the software projects.

And that’s what the DevOps is bringing on: better co-operation between the different parties involved!

Definitions of DevOps

There are probably as many definitions about DevOps as there are organisations involved with it. But the following AgileAdmin’s definition of DevOps is the best I’ve seen: ”DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.”

To simply put, the idea is to enforce and empower co-operation and participation between the different parties.

The IT industry is evolving and changing rapidly. There’s an ever-growing need to improve products’ time-to-market, so there’s no space for silo-focused thinking any longer. Designing, developing, operations and retiring the product must happen as quickly and smoothly as possible. That’s where DevOps enters into the game.

There’s an ever-growing need to improve products’ time-to-market, so there’s no space for silo-focused thinking any longer.

It’s also worth noticing, that there’s a big difference between the Agile methods and more traditional project management methods. In the Agile world the idea is to build the product or service piece by piece, little by little. When following the Agile method it’s not clearly known what the final product or service will be or how it will look. Development is done in small steps and there won’t be too many new features implemented at the same time. Developmental phases, so-called “sprints” are usually measured by days and in some cases even in hours.

In the more traditional software development there’s usually a fixed specification which describes how the product or service will look like when finished. There’s usually a somewhat-fixed budget to cover all the expenses of the project. The project itself can be gigantic and the time frame can be anything from months to years.

Responsibilities in DevOps

Let’s face it: in the old world there was a number of people supporting and maintaining the systems. In the new DevOps world there’s no need for so many pairs of hands, because the idea is to automate processes as much as possible. DevOps should steer the operations of products and services to the new normal were the manual routine work is no longer needed in a large scale.

There are also many things in development phase that have been previously made manually and will be automatised. says the following: ”In the DevOps world there’s been an explosion of tools in release (jenkins, travis, teamcity), configuration management (puppet, chef, ansible, cfengine), orchestration (zookeeper, noah, mesos), monitoring, virtualization and containerization (AWS, OpenStack, vagrant, docker) and many more. While, as with Agile, it’s incorrect to say a tool is “a DevOps tool” in the sense that it will magically bring you DevOps, there are certainly specific tools being developed with the express goal of facilitating the above principles, methods, and practices, and a holistic understanding of DevOps should incorporate this layer.”

So DevOps combines a number of different tools under the DevOps umbrella.

In my opinion it’s absolutely great that many boring prone-to-error routine-tasks will be handled automatically by a bunch of tools. But it would be a lie to claim there wouldn’t be any impact on the number of personnel involved in the developing phase. Of course it does! There will be less demand for i.e. people doing module- and performance testing, (manual) configuration management and so on. Many things like application performance monitoring and continuous integration have been automated to a greater extent etc.

I have pretty often come across a claim that ”now they (developers and operations people) have more time to focus on developing and continual improvement activities”. While this is of course true to some people, there are and will be people who simply don’t have any meaningful tasks to do any more. That’s the way it goes.

In my opinion it’s absolutely great that many boring prone-to-error routine-tasks will be handled automatically by a bunch of tools. But it would be a lie to claim there wouldn’t be any impact on the number of personnel involved in the developing phase.

Then there are also (bad) examples on how Dev(elopers) have been forced to take over the responsibilities of Op(eration)s people. That leads to a bad situation. Mr. Jeff Knupp has addressed this problematic in his writing very clearly.

He discusses about the Totem Pole and he expresses an idea that there’s a hierarchy of usefulness of technology roles in an organization and that Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole. He states that each role can do the job of all roles below it if necessary.”

Forcing developers do all kinds of tasks leads to the situation where developers get frustrated and they cannot show or use their best abilities. So even though I completely understand that in a startup company people end up doing almost everything, I totally agree with Jeff Knupp that not every company is a start-up and that whenever possible “let developers write code!”.



I personally really, truly like the idea to bring people to work closer together. It surely helps tackling silos away, improves transparency and most probably shortens development-cycles and thus shortens time-to-market of a product or service. I believe in DevOps in that sense and I’m sure when correctly utilized, DevOps can keep its promise.


But then again, if you think of introducing DevOps in your organization because of cost optimization, be sure not make the mistakes Jeff Knupp addressed.


Pictures are from Pixabay.

ITIL® is a Registered Trade Mark of AXELOS Limited.


SIAM – toolwise considerations (reporting)

Tools in the multi-supplier environment

I was watching a video ”Talking ITSM & SIAM in different languages” on Cherwell web pages with PhD Ms. Tuuli Sutinen as a guest and AllthingITSM’s Simone Jo Moore, Kirstie Magowan, and James Finister were the other participants. They were discussing about various things, but what I paid attention to was Tuuli’s notifications about SIAM and the question of different tools in the multi-supplier environment.

I think Tools is one of the most essential things that make a difference between success and failure in SIAM.

Why’s that?

Let’s assume you are the SIAM Operator, responsible for delivering end-to-end services to the customer. Everything is ready: customer knows what they are doing and why, their business requirements have been carefully considered, and all the SLA contracts and underpinning contracts with suppliers and other stakeholders have been agreed on. Just like discussed in my previous blog text SIAM – The Good, The Bad and The Ugly.

Customer reporting

The Governance model says you are reporting to the customer once a month, and it’s time for you to prepare the very first service level reports. In order to simplify the issue a little, let’s focus on the idea of reporting about services performance.

Now, what do you actually do?

Suppliers deliver the reports to you. As this is the first time you haven’t probably managed to agree about the common design and layout, not to mention the details just yet and you will receive reports with different styles with different number ratios, dimensions, charts etc. etc.

Ok, you probably manage to collect the reports and manually edit a slideset which will somewhat satisfy the customer’s needs. And the numbers are good, of course, it helps here. J

As this is the first time you haven’t probably managed to agree about the common design and layout, not to mention the details just yet and you will receive reports with different styles with different number ratios, dimensions, charts etc. etc.


At the same time you know that this practice has absolutely no future whatsoever. You can not be editing n pieces of different reports templates on Excel, and/or PowerPoint or KeyNote every single month. There’s no way you could do it and neither makes it any sense.

Improving reporting

A quick win might be to agree with suppliers to deliver the reports on templates you have provided them. That might help a little bit and at least those different reports might be of the same style, so your manual reports compiling work might go down ~ 80%.

Now that’s a lot better and you could maybe live with the situation.. No, you don’t want to settle with that arrengement.

A Finnish IT Company Tieto has stated it quite clearly: ”Good SIAM (Service Integration and Management) tools support the wide range of SIAM processes in a multivendor environment. Because the integration layer needs to support all vendors, present and future, industry-standard interfaces are a must.”

I’d recommend make the necessary integrations between your reporting tool and the suppliers’ systems. Don’t think about ”saving money” here!

Reporting relies heavily on the ITSM tool in order to gain necessary ticket data. In addition to that you most probably need another tool (hopefully integrated with the ITSM tool) or a comprehensive add-on with extensive data analysis capabilities to be able to report an overall situation of the services to the customer.

I’d recommend make the necessary integrations between your reporting tool and the suppliers’ systems. Don’t think about ”saving money” here!

Don’t forget about the status of the other services: You might also need reports about server/services availability, information security, response time of your services etc.

You might actually drown into the river of ever-growing reports. That’s why I would try to agree with the customer about 4-6 the most important reports and make sure those will always be handled, while the other reports might be stashed into the nice-to-know pile.

Customer’s dashboard?

But how about customer’s view? Should your customer have an own view on the tool to be able to check the situation every now and then – and ask questions about their observations?

What’s your opinion?

[ ] Yes!!! Of course they should! They could monitor the situation whenever they want to and they might notice something the SIAM Operator doesn’t.

[ ] Why not. Who would it hurt?

[ ] They don’t need it because they can always ask about the current situation from their SIAM Operator.

[ ] Absolutely not. Customer doesn’t even want it.

What is the correct answer? I don’t know! There are some issues I can address, though. Customer has decided to go with the SIAM model, so you can jump to the conclusion they don’t want to be actively monitoring the situation all the time. They rely on their SIAM Operator. Then on the other hand, I wouldn’t be too surprised if your customer would some time want to see or check out something, so maybe categorically denying the possibility might not be a correct answer either.


There’s no clear-cut simple answer. If your customer wants the view on the dashboard, that can probably be arranged, but if they hate the idea, they have the right to do just that.

Please note: I was only discussing about reporting –related tools here. There are much more into it than this, for example CMDB tools, Asset Management, centralized Event Management, Capacity, Demand and Licence Management tools. I might write about them someday.


So you have read all the way down here and I haven’t told you what is the best tool money could possibly buy? Sorry to tell you, but it depends on so many things it would be impossible to list all the available reporting tools let alone the situation factors here. I would, however, lean on to Remedy’s ITSM tools, or maybe ServiceNow toolset, and power them with some rock solid BI-reporting tool. But what suits for me might not suit for somebody else.

However, one thing is for sure: Tools themselves won’t do the job for you, but without proper tools you are doomed to fail. So don’t underestimate the importance of tools!

Pictures are from Pixabay.