The key to scaling a software engineering organization is stable teams. A while ago I wrote about the need to focus on stable, autonomous teams. Teams with members that trust each other and thereby become more than the sum of their parts. That is, in the end, the ultimate dream of a software development manager: to create cross-functional, self-organizing, high-performance teams. Teams self-organize around a compelling mission and have a.
Ian Bogost’s “Programmers: Stop Calling Yourselves Engineers” in the Atlantic, claims “The title “engineer” is cheapened by the tech industry.” He goes on to state: When it comes to skyscrapers and bridges and power plants and elevators and the like, engineering has been, and will continue to be, managed partly by professional standards, and partly […]
Over the last couple of years the engineering team at Mendix has grown fast. Over the last 1.5 years the team has almost doubled and we are still looking for bright minds. There is a lot that can and will go wrong if you grow this fast. Here are my four most important lessons learned during the process (disclaimer: a lesson learned doesn’t necessarily mean that I execute it flawlessly.
The post Lessons learned in managing engineering team growth appeared first on The Enterprise Architect.
Software is eating the world! Every company is becoming a software company. If companies don’t, they cease to exist. Just imagine: you are a thermostat maker and suddenly you have Google as a competitor (via its Nest acquisition). This is just one of the many recent examples. Interestingly a lot of the innovations in the software industry are fuelled by abstraction and automation, concepts that are well-known in the Model-Driven.
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.
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?
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.
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.
Earlier this year a Technet sponsored study showed that in February there were roughly 466,000 jobs in the “App Economy” in the United States. This so-called App Economy had zero jobs just 5 years ago, before the iPhone was introduced. The term “App Economy” isn’t formally defined but is often used to refer to the economy that has been created due to the development and delivery of software applications for.
Print PDF Guest post by Tim Mattix and Mike Mariani If the relationship between developers and business users is like a marriage, sometimes the CIO’s job is akin to a marriage counselor. In a marriage, one spouse often wants the other to change. In the market, business executives want change, too; changes in the way systems operate so they can capitalize on new opportunities. And often the complaints in both situations are the same. It’s […]
If you liked this, you might also like:
Print PDF Written with contributions from Michael Mariani, Tim Mattix, Ryan Finnamore and many others. You might think the word “agile” is synonymous with “paralysis” to see some organizations react to the idea of introducing agile development principles to their traditional systems development lifecycle (SDLC). Concerns about introducing too much change to the organization can stop agility discussions with the business before they start. But if the organization’s goals include increasing the speed of development, […]
If you liked this, you might also like:
Print PDF A few years ago, a consumer products company I’m familiar with committed to outsourcing its infrastructure and as much of its application portfolio as possible. Its strategic application decisions were heavily influenced by outsourced and SaaS offering, placing its CRM and several customer community sites in the cloud. With a stable set of hosted, cloud and SaaS apps, they were shocked to find that they didn’t talk to one another to provide a […]
If you liked this, you might also like: