The Evolution of PaaS in the Enterprise

by

This morning I was part of a panel at the GigaOM Structure:Europe 2012 conference in Amsterdam., titled: The Evolution of Private PaaS solutions. The abstract:

Enterprises are starting to take interest in running PaaS solutions virtually, as app developers want to focus on building apps rather than dealing with infrastructure issues. Enterprises that use PaaS solutions almost always go down the private route. In this session we focus on private PaaS offerings and look at the considerations and what will happen if one day enterprises want to use PaaS solutions in the public cloud.

The idea was to discuss private vs. public PaaS and, as it was a theme throughout the conference, the differences in adoption rates in the US vs. Europe.

You can view the full video coverage of the panel at the GigaOM website.

GigaOM Structure 2012 - PaaS Panel

Here is an overview of some statements made during the panel to
highlight some of the discussions (in my own words, so could be biased,
but you can watch the video to make up your own mind 😉 ):

Public vs. Private PaaS

Enterprises want PaaS within their own environment, behind their firewall, i.e. Private PaaS.

Public PaaS is focused on the lowest common denominator, limited to certain framework, database, etc. Private PaaS adapts (can/should adapt) to everything used in the enterprise, any language, framework, database, etc.

In our customer base we roughly see a 50%-50% split between applications deployed on our Public PaaS vs applications deployed on our Private PaaS. It mainly depends on data, integrations, and policies.

Mobile is actually helping public PaaS adoption. It is a new subject, and within such a new space enterprise seem to be more open to new ideas.

PaaS and productivity

PaaS is a huge enabler for Cloud Computing. PaaS is “clicky-clicky”: development and deployment that took months brought down to minutes.

PaaS is more driven by productivity gains than the need to move to “the cloud”. The business wants a solution for a business problem. Fast. Keep evolving with the changing business. PaaS should cover the complete application lifecycle.

A PaaS covering the application lifecycle in this way requires a new way of thinking. Connected to agile, continuous integration, etc.

PaaS can help to transfer old way of working seamlessly to cloud. It is just a small step.

No, you need to change the way you work. Modularize applications, no application silos.
If you really want to speed-up. We should also stop programming, start doing MDD.

MDD is possible now… no programming involved perse (also read: Why aren’t we all doing Model-Driven Development yet?).
Enterprise are adopting it.

PaaS should add a layer of abstraction. It should add a software layer. Key is that it is just the first step. New language constructs will abstract even further.

PaaS and the application lifecycle

PaaS can bring harmony between operations and development.

The opportunity is even bigger: it can bring all stakeholders in the application delivery process together. Even end-users providing feedback, and business owners collaborating on requirements. The complete application lifecycle should be covered by PaaS. Not only covered, also speed-up.

Even end-users doing app development and deployment?

Back to private vs public. I believe in hybrid. Even if enterprises want to go with private PaaS, they often want to have development and test environments in the public cloud. Once they start using production data in acceptance or actual production they move the app within the premise of the company.

Real-time updates and modularity

OSGi has been mentioned a couple of times, what is it? A dynamic modularity system for Java. The only industry standard that enables modularity, currently in the Java space but will become available for different languages.

But… enterprises are not asking for OSGi or these kinds of standards.

No, they do not ask for OSGi specifically. But if an enterprise starts to user your PaaS you will encounter something like this: build first small app fast, in an agile way with a small team.

If they start to build a huge app, i.e. with a lot of functional components, people will start to think about modularisation. If you want to release a new feature you do not want to redeploy the complete app. But only the changed component, and if needed the dependencies of this component.

Customer ask indeed about real-time updates in PaaS.

Version/configuration management becomes important: what version of my software is running. And what versions of all the components?

Layers

PaaS is about virtualising away lower layers. However, PaaS can also bring back to the table an understanding (and management of) what an application actually needs with respect to the underlying infrastructure, e.g. data needs to go over the same switch, caching is sensitive for locality, etc.

There is no clear distinction between layers. IaaS and PaaS players are moving into each others space. Amazon started out as IaaS, but nowadays delivers a lot of higher level services that you could categorise as begin part of the platform layer. Microsoft Azure and Google are moving the other way around: from PaaS player to also delivering IaaS.

Is there room for language specific PaaS?

It depends: if you only have .Net it makes sense to have a .Net specific PaaS. However, most organisations are heterogenous. So you need to support multiple languages.

You see that because we are in a transition, people still use their current methodologies. As PaaS becomes stronger, full stack, there will become PaaSes that focus on one language. That will need a different way to build the application. Because you need advantages like auto-scaling, dealing with locality, etc.

If you really want to change, you need to disrupt. Do not cling to your existing methodologies and languages. I truly believe there is a big opportunity for PaaSes with focused languages.

Forrester defined space within PaaS: new productivity platform. Step to higher level languages. Different roles that build applications.

Platform should run components defined in all kinds of languages.

It depends on how you define PaaS. It is not just a deployment platform. It should also cover the other aspects of the application lifecycle like development and maybe even requirements/feedback management.

If you really want to disrupt the field and make it a lot easier and faster to build applications (that’s in the end what businesses are looking for), than you also need to change the way you develop applications not just the way you deploy it.

PaaS adoption in Europe vs. North America

Interesting thing last 2 years: not really a difference. Everywhere businesses are looking to improve their software delivery. There is no business innovation nowadays without software delivery involved. Businesses want improvement, productivity gains.

Then the question is will it be a private or public PaaS. We see the same thing in US and Europe: it depends on the kind of data and the kind of company. Banks will probably go for private. But a lot of other companies will go with public PaaS, especially for their customer facing portals.

It all depends on the usecase. Not on region.

PaaS often starts small.

That’s an opportunity. We take a week to create a working app for new customers and they have something tangible to show within their own organization.

No difference between Europe and US. Almost all private PaaS.

It seems like we are saying that if you are an enterprise of course you will have private PaaS. That’s not true. A lot of big companies are using public PaaS. Of course there are enterprises that go with private PaaS, but it is use case dependent. Not dependent on the size of organizations.

Why do we see so much private PaaS? Well, it could be that if you product supports private PaaS that it is a lot easier to sell that.
People feel comfortable with private PaaS, that’s what they are used too. If they get used to the idea of cloud and see advantages they will move.

Power and politics in enterprise-architecture

by

Anyone who’s involved in any form of enterprise-architecture would know that it’s best described as ‘relentlessly political’: seems almost everything we deal with turns out to be some kind of tortuously-intransigent wicked-problem. Which in turn seem so often to be rooted…

Agile Manifesto for the Enterprise

by

The Agile Manifesto is rightly held in high regard, but most practitioners understand it was a response to the prevailing environment in 2001. In fact I note Scott Ambler attempted a rework of the manifesto in 2010. Specifically Scott replaced software with solution; customers with stakeholders. And in context with the Principles behind the Manifesto, he suggested improvement of the overall IT ecosystem be taken into consideration and that Agile can benefit from the Lean Principles.  

But many organizations are finding it hard to scale Agile in the enterprise and much of this difficulty is because of the adherence to specific Agile guidance. In developing the Agile Enterprise Workshop (more on this very soon) I feel it’s imperative to have clarity of how we interpret the Manifesto. So I am using Scott’s work as a basis for addressing key enterprise issues as follows:

Individuals and interactions with lean processes and tools
Working services and solutions with essential documentation

Stakeholder collaboration with agile contracts

Responding to change is intrinsic to the plan

Delivered agile architecturewhich reuses and evolves enterprise frameworksand patterns

I’m afraid this renders redundant the preference for the value of items on the left over items on the right.  In addition the introduction of architecture, whilst it may be highly controversial, is essential at enterprise level, where the level of inter-dependency is so high, and the cost of delivering yet more legacy is unacceptable. Strangely the preference of left over right might actually be reasonably applied to the architecture point.

As Scott rightly said, “We’re agile – things evolve, including manifestos”

All comments appreciated!

Business Architecture enables Tactical “doers” to implement Strategy – Part 1

by

I just read an interesting article by Nacie Carson, author of The Finch Effect, on the need of operational teams to act tactically in support of strategy. In this article titled As Chocolate Is To Peanut Butter, Strategy Is To Tactics, she particularly focuses on the ability of the team leader to straddle both strategic thinking

The post Business Architecture enables Tactical “doers” to implement Strategy – Part 1 appeared first on Louise A Harris on Enterprise Business Architecture.

Don’t Think You Are, Know You Are!

by

Today Tom Graves has neatly described Two Enterprise Architectures and by that explored the difference between Enterprise IT Architecture and Enterprise Architecture. I have touched that topic shortly in my post about Real Enterprise Architecture. I am…

Categories Uncategorized

Guide the Energy

by

As I have written in my last post Less is More reducing complexity to the absolute needed minimum is key to not add unneeded clutter and blurriness. I also touched shortly on the energy created if two (or more) ideas compete for the limited attention a…

Categories Uncategorized

Don’t Get Distracted by the Document

by

This may seem like an odd blog coming from a company that is so deliverable focused, but it isn’t. A design document is not just a document, but a powerful tool for figuring out an architecture. However, it is easy to get caught up in the “task” of completing the design document and lose focus […]

Alex Osterwalder’s Business Model Canvas

by

Alex Osterwalder, entrepreneur, “Business Model Generation” author and creator of the Business Model Canvas, discusses how enterprise architects can contribute to business models. He suggests that there needs to be a bridge between Enterprise Architecture and the highest strategic level of business, bringing strategic and implementation concepts together. Continue reading →

The Business Architect’s Service Portfolio Part One: Strategy Development and Articulation Services

by

For some time now I have been promoting the idea that the practice of business architecture is not about creating blueprints and models but applying a set of tools and techniques to form broader perspectives, create deeper insight, and solve business problems. If business architecture is a practice then what is its portfolio of services? […]

Agile Business Conference 2012 Report

by

Last week I attended the Agile Business Conference in London. With four concurrent tracks and well over 200 delegates this must of necessity be a report from a personal perspective.

In the opening keynote Diego Lo Giudice from Forrester encouraged the thinking that we are moving beyond IT centricity and IT ownership into a Business Technology world. This was supported by other speakers. Kevin Herry and James Yoxhall gave an outstanding talk on how IPC Media integrated agile, incremental project delivery with evolving business priorities by using value based backlogs and metrics. However it did leave me wondering whether the IPC Media situation was very specific because the business value could be measured with readily available web site measurement tools. In less well instrumented business situations measuring business value is a hard task, and this was reinforced in the special session on value based contracts.

Diego also used the metaphor of the Crown Jewels, a very British concept I guess, to advocate using Agile selectively for maximum benefit. Being an industry analyst of course he was almost bound to show some industry adoption numbers, and these certainly supported the assumption that most organizations are using Agile very selectively. This intelligence was also corroborated in my own discussions with numerous delegates who agreed that Agile is hard to scale out.

However to rebut this to some extent, there was an outstanding talk from John Flenley of SITA (Société Internationale de Télécommunications Aéronautiques). Together with four colleagues, he explained how the endeavour to replatform and modernize common systems and services used by airlines and airports worldwide had been transformed by a highly structured, very large scale Agile approach. In the process John demolished a number of sacred cows (apologies for the mixed metaphor) and described a functionally baselined modernization process using pre-sprint knowledge discovery and specification processes which fed multiple concurrent, distributed (i.e. not co-located) development sprints! In addition they contracted with no less than three outsourcing providers using fixed price contracts based on Function Points. Key to the program’s success was a tight focus on automation and metrics and measurement across the entire life cycle, and the use of rework measurement as a key to governance and program management. My own notes on the session were heavily annotated with the comment “back to the future!”

Another outstanding talk from Dave West of Tasktop, and perhaps better known as the ex Forrester analyst supposedly responsible for coining the term Water-Scrum-Fall. His theme last week was automating ALM, and here he was (see comments below on WSF) on firmer ground. I have long railed against the Agile community that is so heavily People and Process oriented, and so little interested in architecture and automation. So it was a breath of fresh air to hear someone evangelizing full life cycle automation across tool and participant ecosystems. He advocated the concept of the software supply chain in which ecosystems collaborate using tool integration, buttressed with defensive programming mechanisms and automated testing to establish separation of concerns. Yes! Sounds like a service architecture to me. Dave agreed there is a real need for better standards and meta models in this area, which are currently woefully inadequate, and it’s great to see this topic getting air time at last.

Talking about Water-Scrum-Fall, Manav Mehan from TCS recounted his experiences of using the hybrid method and argued that a) using Agile delivery together with largely unchanged planning and requirements  processes is a given for most enterprises and b) that hybrid is merely a stage in a longer term adoption and maturing process. He also described how they gradually evolved the planning and requirements processes. However he explained he received so much negative feedback about the name Water-Scrum-Fall that he changed the name to I3 (Interaction, Incremental, Interactive). Speaking to Manev later I asked whether in retrospect he wouldn’t have been better off just referring to the approach as agile? I’m afraid in my opinion, Dave W’s contribution in this area is less of a step forward and more like a legacy.

And finally to the topic that was almost absent from the conference – architecture. For me architecture (and technology) is at least as important in delivering agile business as people and process, and because I was manning the Everware-CBDI stand I had great opportunity to engage with delegates on the topic. And I can report wide agreement on this point. I attended one session on architecture and it was an interesting user experience, but to me this is an area that, not just conference organizers, but the agile community at large need to engage with.

There’s much more. I haven’t mentioned governance, which was in evidence, but to be honest didn’t impress me too much. More work to do methinks, particularly demand management and architecture governance.

I will leave the final word to Stephen Grafton who ably chaired the keynote and panel sessions. He said, “We are still struggling to define agile with a big A or not!!” And this summarized the conference. There is really good experience with Agile in smaller, tightly focused, or larger highly standalone situations. But for the typical enterprise looking to deliver more broadly based agile business, there’s a great deal of learning required.