Product Manager? Product Owner? Service Owner?

In recent weeks, I have been in conversations with people inside as well as outside the company about how to effect cloud-enabled transformation.

There are new certitudes in play. “We must be cloud native,” “We are going to be agile” (maybe lean as well?), “We aspire to deliver faster using continuous delivery/ continuous integration”, and of course, “We’ll treat infrastructure as code.”

I think I may need to include DevOps or DevSecOps — but out of sheer perversity, let me add Finance to it and call it DevSecFinOps.

The small fly in the ointment is, well, a bunch of silos, lack of skills and no clear roadmap on how to get the as-is model to the to-be model.  Often the tech stack, the architecture and the development model are the easy bits; there’s lots of blogs, articles, training, etc that can take a small team and enable them in the new technology and practices.

One can hire experts, but also provide training in the new stack to the engineers, and one can get going. Add some Agile training or SAFE if that’s your environment (People argue for and against SAFE — not the subject of this blog).

All of this can get an organization started on the road to cloud in some shape.

But I have a question, who is the product owner? Or who is the product manager? I wrote about this role back in 2011 and it’s still astounds me that enterprises don’t have a ready answer. My friend Wayne Greene has a good blog and book on the product management topic.

And yet the role is unclear.  I think the product owner role in Agile needs to be made more explicit.  My question starts with: how much power does the role have? Can they change requirements? Push launch dates? Do they own the success of the product? To use an old adage, are they the CEO of the product?

I have owned the role in small software companies, in my own startup as CEO, CTO,  and in some very, very large companies. And while it varies, the ultimate responsibility of the role is to drive the success of the business through product innovation aligned with the company strategy and the sales channel.

Product managers should not have to be empowered; they must have the power to drive the product. If your digital transformation or org model does not have the role and the functions it manages in place, you should treat as a major risk to the effort.

Why? Two reasons: one, your ability to respond to market changes and coordinate all the necessary functions will be compromised, and two, you won’t be able to recruit the talent you need to drive the business.  The professionals that can drive the business will realize it’s a losing battle and avoid the company; the job will be seen as a loss of stature.

These are not my final thoughts on the topic but my observations based on how difficult it’s to define the role of product owner / product manager compared to other roles in the agile transformation.


You want cloud native apps? You may need to lift (and shift)


Last week, at Google Next, there was a lot of talk about Apps built on the wonderful new abstractions and platforms cloud providers and PaaS providers are bringing to market.

These apps are sometimes called cloud native.  And in 2017, it’s the way to engineer new apps.

But what about the existing apps? The other 99% of the portfolio?  The answer for those is to migrate them, as-is, to the new cloud platform in the least disruptive way possible.

This “lift & shift” is sometimes dismissed and / or belittled by some of my cloud friends as not being real cloud.  They are correct. It’s not “real” cloud –whatever purity test that entails.

These apps won’t scale out or failover to a new region. In fact, the old apps running in the new cloud bring in all the old management processes such as ITIL into the new cloud environment.  The question is why even bother?

My answer: it’s a necessary transitional step towards cloud adopti0n.  Here’s why:

  • You can’t re-write every app in a large enterprise in any cost effective or time relevant way.  So dispositions and priorities will have to be made and much will have to be migrated as-is.
  • Apps travel in packs. If you have ever seen an ERP diagram of all the systems it touches, it becomes pretty clear the “APP” is in fact a composite of many sub-systems. You can’t just move one component; you must move all the ones which have to be together in one wave.  This is something we do at very large scale day in day out; so I see it in practice.
  • Many enterprise apps are actually commercial off-the-shelf software  (COTS)products. In fact the core ERP systems are all COTS. The enterprise has neither the code nor the expertise to re-write these app and the vendor may have no plans to offer it as SaaS.
  • For every app, a disposition has to be made. Re-write? Remediate? Modernize? Lift-and-shift? Remove? Leave as-is until end of utility?  The application portfolio view and the dependencies between components is a key piece of work to asses readiness to move to cloud.

The second bullet point is one of the main reasons to migrate (lift and shift) workloads to the cloud. New, cloud native apps that extend or replace components of the older app can more easily be considered once the old apps are in their new cloud hosting environment. From security to networking to assurance, all these processes can now be carried out in the new cloud thus spreading a set of fixed costs  over a larger set of apps.

Wither the datacenter?

Once an organization has committed to adopt public cloud, a mental clock starts ticking; what is going to happen to the datacenter?  Keep it, and for what? Renew the lease? Close it?

And if half the apps go to the cloud but half remain, will the application owners be happy if their hosting costs double? After all with fewer  tenants, the higher the allocation rent.

The reality is no app owner wants to be left holding the last app in the data center. This starts the planning cycle to shut down a datacenter.

You must vacate the premises by a certain date in order to free up the capital or opex and move to a cloud.

That’s the forcing function: avoiding a data center lease renewal or avoiding building one, and freeing up capital.  Hence the need for lift-and-shift.

People who are planning large migrations to cloud are aware that this doesn’t really change the quality of the service or make the app better, initially

But they know they will be in an environment with a richer set of services. Which sets the stage for app modernization.

A real case study: Accenture Cloud Platform evolution

My own area is a microcosm of what I just wrote.  I’m responsible for a software product offering called Accenture Cloud Platform. We architect, engineer and deliver a complete cloud management platform as a service, billed ion a consumption model. We offer a range of services, from cloud procurement, brokerage, cost analytics, managed billing, workflow automation and many other managed services.

In early 2014 we stirred, shook, and moved our apps from an internal data center to the cloud.  Our cloud management offering is made up of many underlying software components: three tier components (web, app servers, databases), open source components, COTS components (including one that requires a Windows Server), plus a variety of tools like back up servers, monitoring, patching, antivirus, application performance managers, user tracking, and more. An enterprise cioppino of software.

This whole stack si dedicated to delivering great cloud management services for our clients.  Step one in going to cloud? We lifted and shifted the entire stack to the cloud.

Once we were stable and comfortable in the new environment, we started modernizing.  No more SQL but now use SQL as service. No more load balancers, we adopted native DNS, and the native data warehouse.

At the end of 2015, we faced the need to build a whole new discovery and policy component for our offering. From managing thousands of VM’s, the next challenge requires us to manage billions of items.

We chose to go all in serverless for this new component; it would sit along side the older components (see prior post).  This May we will deliver brand new functionality for our offering; this time using a modern web-native stack.

This is why lift and shift is strategic. Once one can operate in the new environment, one has  the option to modernize and incrementally re-write components while adding value to existing operations.

In theory, one could execute this strategy without a massive lift and shift. In practice the cost of network modernization in the datacenter, the complexity of security design, and the need to modernize the old apps in the old infrastructure to make them “sufficient” to work with the new apps make this scenario unrealistic. Better to lift and shift.



The Accenture Cloud Platform Serverless Journey

Last week at AWS ReInvent, my team presented the architecture of the next generation of the Accenture Cloud Platform which uses a serverless approach.

We started this journey November of last year to solve a set of business challenges which are common to any product group in a large enterprise faced with a fast growing market disruption like cloud.

  1. Speed.  Given how quickly cloud services are evolving the challenge we faced was how to add support and management to these services at speed.  Our traditional approach meant falling further behind every day; AWS claims they are adding three major features a day.
  2. Budget. While cloud services are growing at very high rates, our engineering budget will not grow. We needed to have a way to disconnect cloud growth from cost growth. The only way to do that is to create a true platform that allows other  members of our ecosystem to serve themselves and others. Think of it as Tom Sawyer getting other kids to paint the fence, but in a win-win approach.
  3. Commercial alignment to market needs. It’s no secret that customers want everything as a service and to pay on a unit consumption basis. The challenge is the number “units” of measure is growing rapidly.  Serverless allows us to dial the unit of consumption all the way down to a specific customer function, like “update CMDB” or “put a server to sleep”.  And it’s done at a prices that are fractions of a penny.

As I said to address the speed and budget challenges, we created an architecture that provides room for third-parties to add features and interfaces without needing our team to be involved.  We defined three speeds of delivery and created rings. In ring zero we deploy code multiple times per day and it’s where core multi-sided, multi-tenant platform lives.

In ring one, we bring features out on a monthly basis.  A different engineering creates the standard features and functions users of ACP “see”.

And in ring two is where client projects live. ACP is a platform that can be extended, integrated and tailored for specific customer uses. Besides generic cloud management, it’s always necessary to stich together both new and existing operational models. Roles, access, systems, services, etc all have to be integrated into one control plane to effectively use cloud at scale. Most one-app startups stitch their own; enterprises have literally thousands of apps so we offer our own ready-to-go platform, delivered as a service.

These projects have their own time frames. It’s here that our ACP serverless architecture delivers the greatest value. If a client needs a new service x managed, a simple guide and set of API’s enables our consultants to extend the platform in a secure, stable and supportable manner.

To be clear, ACP is a large platform. There are components that are traditional three-tier apps and others are commercial products.  Our journey is about the components we build to make ACP be a platform.

I suggest you watch the video.  My colleague Tom does a brilliant job

Accenture Cloud Platform Serverless Journey

Where Did Your Machine Learning Algorithm Go to School?

The Russian Machine

One of the hottest areas today is Machine Learning (ML).  It will do magic. Cure cancer (literally) and free humanity from drudgery. Which is so naive. Humans have infinity capacity make a mess of things. One day the machines will learn that too.

Recently I’ve been shown some product demos claiming to use ML to solve some aspect of  rather intractable problems. Problems usually worked on by skilled architects or specialized experts in their field.  In both of these cases, the (different) presenters claimed that through ML, it would a) define and architect a system, and in another improve a business process.

I was intrigued and incredulous. I could see some automation, but solving the whole thing?

I did not believe it. But when something is hot and new, we often lack the language, confidence and assessment framework to refute or judge the claims being made. I politely asked a few questions but I felt a bit uncomfortable.  I kind of stewed for a few days.

Finally, I arrived at some questions and way of thinking that will help me have a more detailed dialogue with people making claims based on ML. Here it is:

Schooling. Where did your ML algorithm go to school? Who were the teachers?

Curriculum. If the machine is to learn, it needs data. Lots of data. How much data was used to teach the machine? What was the quality & provenance of the data?  Is it sufficient data for learning to happen? What biases are built into the data sets.

Graduation. What exams did the ML algorithms pass? What grades did they get?

Work Experience. Where and when did they do their internships? What projects and results have been produced?

This framework may seem humorous (I hope) but it’s also useful.

The ML algorithms are only as good as the teachers they have. And for now, all the teachers are human. The ML will only be as good as the teachers.

ML requires a sufficiently large amount of data on which it can learn. This data is actually hard to get!  In the two cases above, there are no data sets that can be bought or used, so it struck me that the ML algorithm would deliver trivial advice, very biased to the one or two experiences encoded. Not enough data to learn anything. And the definition of sufficiently large will vary by problem.

On graduation, the notion of exams to pass your class are the equivalent of Quality Assurance in software development. How do we know someone knows something? We test them.

On work experience, same thing.  Nice that you studied and passed your exam. But work experience is how we know someone actually ‘knows’ how to do something.

In summary, these are the questions I will be asking about ML going forward.

Remember, my opinions only represent my opinions.

Cloud Security Concerns: Welcome to AdventureLand

Now Leaving Adventureland

On a recent visit with senior executive customers in Europe, they expressed concerns about cloud security.  Which is similar to concerns American CIO’s have about cloud.

But they mean something different. For European CIO’s, in addition to the standard concerns American CIO’s share, there’s the “other” security concern: spying by American intelligence agencies.

This fear is a real and grounded. The Snowden revelations of spying with the seeming cooperation of certain internet services, spying on allies politicians, plus the recent revelations about Yahoo’s indiscriminate handling of email do not help. In fact, the FBI, NSA and CIA have done more to support the datacenter business of national telcos than anything those companies could do to compete with the hyper scale clouds..

How do I convince them that in fact cloud is safer than a private data center? As an American?

I don’t.

I tell them that they should assume the NSA, CIA, FBI etc are trying to hack them. As are the Russians, Chinese, North Koreans, and every major intelligence agency in the world.  I tell them we have gone from a world of individual hackers to criminal networks to now nation states.

I ask them how many security people do they have and their level of experience? The answer is usually not enough and not enough. Not enough skills, budget or focus.

How do their capabilities compare to the capabilities of major cloud providers in terms of numbers and expertise? Expertise honed over 20 years of fighting hackers for whom Google, Amazon, Microsoft would be …. the apotheosis of hacking.

Fact is that security in the cloud is a shared responsibility, but one where the underlying service provider brings a skills, experience and scale that most enterprises don’t have in house.

This is why cloud is more secure than a private data center– very few enterprises have the skills, budget to protect against a superpower trying to hack your datacenter.


Startup Choices Rapidly Becoming Enterprise Choices


As I wrote on “The Three Freedoms of Cloud“, cloud is all about agility and speed.  A couple of stories both illustrate and enlarge this point through the adoption of serverless architectures

A Startup Volunteers to Be the Canary in the Code Mine

The first story comes from a startup called Siftr (You know they are a startup because they could only afford one vowel).

The post is on the value of serverless as experienced by a small startup. They chose Google App Engine for their application.  Here’s the relevant quote.

An enterprise, with practically infinite resources at disposal, can afford to be selective about every single component that goes into their tech stack and can recreate the entire wheel. However, for startups, time is gold! Their choice of technology should help them maximize their number of ‘build-&-measure’ iterations and yet should never hinder the product design.

Source: Why choose Google AppEngine for starting-up — Technology @ Siftr — Medium

As a past startup guy, I completely lived this reality.

When I started newScale, we faced a choice of what to use to develop our product. Only three engineers, a short runway of cash, and lack of clarity about our market.  Job one has to be product / market fit.

At the time Java was not really an economic or performant choice ($300K for an app server was the quote from WebLogic; I didn’t see the logic of buying).  C++ (we came from that world) was too complicated, slow and lacked portability, and Perl and those type of languages were unknown to us.

So we chose ColdFusion.

Over the years, I got so much grief for that choice and five years later we re-wrote the app (at great cost) in Java.  So was it the wrong choice?  NO!  That choice allowed to build a rich, enterprise level product, acquire major enterprise clients which let us raise $26M over two rounds.

It was thanks to that initial success that we could afford to re-write it

(New) Reality Arrives to the Enterprise: Fast Eats Big

Market advantages have become transient. The time in which an enterprise could build an effective wall against competitors is fast fading.  Enterprises have responded by beginning to adopt the tooling, practices, and culture of start ups to remain competitive

My friend James Staten, Chief Strategist for Cloud at Microsoft Azure, has some useful research to share regarding the value of moving to PaaS.

Sure, moving your applications to the cloud and adopting more agile DevOps methods will save you money and make your complex application deployments more efficient but if you want the really big gains, focus the majority of your developers back on coding. According to Forrester Consulting, the gains from doing so are massive.

PaaS value chart

Yes, re-hosting or even building cloud-native apps in VMs and containers will give you big gains in agility and cost savings but asking your developers to manage configurations, update the OS and middleware and pick the right virtual resources to support their apps (let alone manage the security of their deployments) is a distraction that cuts into their productivity.

And shares some pretty dramatic numbers about the economic impact.

How much, you ask? In its latest Total Economic Impact Study, Forrester Consulting interviewed a number of current customers of Azure’s PaaS services and concluded that concluded that migrating to PaaS from IaaS resulted in a 466% return on investment. For customers migrating from on-premises environments to PaaS, the return on investment can be even greater. Time to market also improved by as much as fifty percent, because of the efficiency and speed of deploying applications with PaaS services.

James works for Azure but I believe these type of results apply to serverless architectures as a whole. And to be clear, these savings do require the adoption of new operating models such as DevOps. Sticking to waterfall and ITIL won’t get you there.

Also Amazon Web Services

And not to leave Amazon Web Services out, in our Accenture Cloud Platform, we are using Lambda for certain  components.  Our entire system is composed of COTS (we don’t owncode), homegrown components written in Scala, web services from cloud vendors, and now new components written in Python using Lambda.  In other words, not atypical from what you’ll see in a large enterprise that has history and heritage in their infrastructure. Heritage sounds better than legacy.

The value we get is similar to what others are finding:  savings in time to market, flexibility and agility.  And improved costs and security in our case.   Yes, you have to live within the constraints of the underlying PaaS, but that discipline keeps us focused on building value.

But What if It’s the Wrong Choice?

There’s a fear in using these tools that they could be the wrong choice. Well, it could be and eventually it has to be re-platformed, but you’ll either know it quick enough to make a change, or it will be a long ways down the road after you

But if it helped achieve product market fit, time to market, validate market thesis and / or deliver competitive advantage, the fair answer should be: WHO CARES? The business objective has been achieved.

Also, the cost of re-writes and re-platforming is not what it used to be. The cost of constructing new apps has fallen to an all time low thanks to the availability of tools, open source, and web services. In many cases, it will be faster to re-write it than to fix it.

Time to be Rigourous. How to Ruin a Cloud Implementation: Leave Self-Service for Last

I’m republishing this from my old blog. I wrote this in 2011, yet I was having this conversation today.  I realized the move to as-a-Service still requires a methodology. 

Self-service should not be an after-thought in cloud projects, it’s the beginning of the journey.  Self-service drives the standardization of offerings and reduces the labor costs that arise from designing, specifying, ordering, procuring, and configuring computing, storage and network resources on custom basis.

This standardization and automation also applies to application components, security and network services such as LDAP, DNS, load balancers, etc.  I say “drives” because the moment an organization decides to provide infrastructure on demand, three questions arise that are at the heart of the beginning of the cloud journey:

  1. Who are my customers?
  2. What are my offerings?
  3. What are my existing delivery processes?

Like any other business, the question of who are we serving, what do they want to buy, and how do we deliver,  leads to many other questions. These questions are at the beginning of journey to the cloud operating model.

But, haven’t we answered these questions before when we built our ITSM catalog?

Answer: NOT with rigor required by a self-service and automation program.

Once we decide to offer a cloud service, these questions need to be answered with a BRUTAL and RIGOROUS specificity to be codified into self-service choices.  Usually, until the decision to   deliver cloud services, these “customer” catalogs are often vague, warmed-over recapitulation of some well-intentioned static “service-catalog.”

In my experience, very little of that prior work is usable when confronted with the needs of the cloud project. I’m loathe to say it’s useless; sometimes the project team that did the prior catalog is actually in the best position to understand the short comings of the prior work and can be a good contributor to the cloud project.

Getting back on point, once the decision to offer infrastructure as a service to the user community, At this point, the cloud teams faces three tasks:

FIrst, define the customer as a consumer of a set of offerings that address some activity the customer needs to carry out. For example, “test a patch to the scheduling system.”  The team needs to figure out the proper metaphors, abstractions, rules for configuration, rules for consumption, and the choices allowed the customer. And this needs to be in the language and domain of competence of the customer.

This is hard for us technical people. We like lots of choices, we understand a lot of things our users won’t.  The exercise of understanding the customer requires a lot of trial and error.

Sometimes I see some “cloud interfaces” that are really admin consoles to configure compute, network and storage resources. The UI’s are targeted at unicorn users (they don’t exist)  — because developers, the real target of cloud– are usually not network experts, or other than disk space, they don’t know much about storage. Thus this is a unicorn customer–she doesn’t exist!

Second, the cloud team now needs to break down the end to end service delivery processes into it’s component processes, specifying all the hand-offs and activities, the tools and systems used, and the data required to both execute activities and make decisions.

This is where standardized offerings become the difference between success and abject failure as they simplify decisions and data gathering.

If every car is a Model-T, then manufacturing, supply chain, capacity management, procurement, planning are all much easier.  if you have a large variety of options, it’s much harder.  Start small. Amazon web services first compute offering was small linux. That’s it. “sm1.linus” (the original name) is the Model T of the cloud era.

Third, a good gap analyis and coverage plan is needed.   What we tend to find at this stage of cloud design is a gospel of gaps: rules in people’s heads, governance rules that get in the way (hello CAB!), existing systems built for responding in days and weeks rather than minutes and seconds.

Also there are missing systems. Sources of record are unstructured (like a word document or wiki’s) rather than a database or a structured data model.  The few tools that make it lack API’s, were built for a single tenant, do not enforce role-base-access control, or were not designed for consumer use.

Good process design needs to inventory these system and data gaps.

For example, take the task “Assign IP” address. Today, Jason the network admin gets an e-mail, and he opens his spreadsheet and sends it to someone who then assigns it to the virtual machine. Now, we need to enable the user to assign an IP address on self-service basis. So no Jason, no spreadsheet, no manual steps. But we do need to say Yes to a IP Addreses Manager, portlet, lifecycle manager, consumption and reclaim process.

This one example.  If you don’t have simple standards upfront, the number of rules and interactions reaches a complexity where it just doesn’t work and it’s a maintenance nightmare.

Sounds daunting, doesn’t it? Well it is, if the cloud team doesn’t do the proper gap analysis upfront. When they do, it’s just a project like any other.