Guilty! You will find SaaS, IaaS, and PaaS terms in my past research documents and blogs posts. But I have decided to stop using the *-as-a-service moniker because it is a redundant pleonasm like horseless carriage, wireless phone, and absolutely necessary - meaningless because it is excruciatingly redundant.
Does “as-a-service” merely mean that “it”:
Resides in the cloud?
Stop the insanity.
Join me in pledging to eliminate-as-a-service (EaaS) the *-as-a-service term. Darn. There I go again.
In Champions Of Change: The App Dev & Delivery Role In 2020, we began to think about the business climate in the year 2020 and how it affects the application development and delivery role. Building on that theme, turn your attention for a moment to your existing application portfolio.
UGH! Yes, that dark, dank, ugly bucket into which you've been dumping applications, enhancements, and upgrades for decades - that place where even though it is overflowing, only a few intrepid souls have the courage to look. What do you see? Duplication? Yes. Waste? Yes. Needless heterogeneity? Yes. A tangled mess of point-to-point, siloed, marginally integrated apps and data seething and roiling with cost, complexity, and other innovation-crushing-demons?
If you are both truthful and like most of your peers, there is only one answer: Yes, to all of the above! OK, so let's stipulate that's at least partially true for all of us and that there is a chasm between that "place where demons be" and where your business leaders would like to be today. How will you begin to sort it out, state its health and future usefulness, then reshape it toward the future that awaits us in 2020? Do you even try? Here are a few schools of thought meant to spur debate:
Scenario 1 - You don't even try, because you know you'll rewrite all those apps before 2020
May I just point out that your predecessors said the same thing about those 35-year-old COBOL programs still in your portfolio today?
You read that number right: seventy percent, a dramatically high rate of failure. It could happen to you unless you take into account that any business process change is strongly related to personal change — that means your people — and this is often the component that gets shortchanged. Organizations fail to realize the impact of change on the employees it will affect and do not plan and execute carefully enough to address the people issues through all phases of business process change management. Today’s business environment is constantly changing as companies work to stay competitive. But change only happens when workers change their thinking, beliefs, and behaviors. This is hard and requires constant effort from employees and executives.
Change management methodologies abound. Look carefully at ADKAR from Prosci and John Kotter’s The 8-Step Process for Leading Change; read Crucial Conversations by Patterson et al. They are rich in change theory and suggestions. Choose one methodology or components of many methodologies. What’s critical is that you do not miss any of the following six principles:
The change manager (managing the people change) and the project manager (managing the technology change) must plan together; they work in parallel but have constant interaction to make sure the initiative is moving ahead on both fronts.
To make your change management efforts work, follow these best practices:
Get project sponsorship from a leader who understands people change management.
Make sure you have the change management resources and a budget.
Communicate constantly with employees by engaging them in discussions and keeping them informed.
The boundaries of what we mean by “application life-cycle management” continue to stretch and tear, like Arnold Schwarzenegger stuffed into a toddler’s jumper. While we still have to be careful about defining ALM so broadly that it’s no longer a meaningful category, it’s clear that the traditional list of functionality ― task management, build management, requirements, management, etc., etc.― is at least a couple of sizes too small. In fact, the amount of overlap with product life-cycle management (PLM) is so great that it may be increasingly hard to discuss them separately. They may be surprised to find how closely related they are, like Schwarzenegger and Danny DeVito in Twins, but the connection is definitely there.
Even without PLM tugging at it, ALM is stretching to fit the real development processes it ostensibly manages. As development teams are not indifferent to what happens after they hand off their code to the operations people, ALM has been expanding to include more elements of release and deployment. ALM can’t accommodate everything ops-related without ripping apart at the seams, but it does need some alterations.
PLM is a whole different consideration. Rather than expanding the definition of ALM, it adds another layer on top of it ― primarily to accommodate the realities of embedding software in other products (cars, refrigerators, medical devices, etc.). Because the number of these hybrid hardware/software products expands daily, the urgency of figuring out how ALM and PLM fit together as part of a common ensemble has been increasing.
Today, Tibco Software — best known for its SOA integration, complex event processing, and business process management suite — announced its acquisition of Nimbus Partners, a privately held business process analysis vendor based in the United Kingdom. Nimbus Partners is smaller and less well known than the other more mature and full-featured BPA solutions, such as those from ARIS, Provision, and Mega. Nimbus, which employs more than 100 people, sold process discovery and authoring tools along with its homegrown methodology for quickly capturing and managing detailed information on business processes. Nimbus’ features and ease of use appealed mostly to process architects, process analysts, and business stakeholders that wanted an environment more robust than Microsoft Visio but not as technical — or requiring as much training — as other BPA environments.
How many times have you heard the following phrases?
“This software bites.”
“Why is software development always delayed?”
Both sentiments describe the need to design and build software that provides a great user experience (UX) and that is delivered in a timely manner. Luckily, there are two communities focused on both of these goals:
The user experience gang focuses on designing software the users find useful, usable, and desirable.
The Agile camp focuses on delivering working software to expose functionality that users can test.
Complexity is the nemesis of application developers everywhere. While software products' complexity may be, to a great extent, unavoidable, we don't have to complicate software development to match it.
That's the conclusion driving many of the new approaches that app dev teams are embracing. For example, Agile breaks down humongous, complex projects into incremental deliverables that are far easier to scope, build, test, and deliver. Lean practices simplify processes, making it easier for teams to achieve a state of flow. DevOps advocates are trying to eliminate the needless complexities that result from throwing software over the wall from one team to the next.
But there's more to Agile, Lean, and DevOps than just a common enemy. It's no accident that practitioners often speak of this trio in practically the same breath. The Kanban board is the symbol of this convergence of practices. Here's an increasingly common use case: an Agile teams uses a Kanban board to manage work with other groups, including the DevOps team.
The evidence for this convergence is more than just anecdotal. When we survey app dev professionals, they report that they're mixing methodologies all the time, including Agile and Waterfall. For a variety of reasons, Agile teams have made the adjustments necessary to accommodate Waterfall. Not every planning activity at the beginning of a project can be handled in a strictly Agile fashion, and not everyone involved at the end of the project (release management, operations, and business users) is necessarily sold on the idea of rapid, continuous delivery. If you work in a regulated environment, you're required to take extra steps at the beginning and end of a project.
A quick reality check: our content & collaboration systems have been with us since we first put PCs on desktops. Today, these systems are pervasive in our workflow, our work lives, and our work cultures. Need proof? Here are some data from our recent survey of 4,985 US information workers:
91% of information workers use email. Email's still the most ubiquitous and important collaboration tool, but hardly the only one that people use.
58% of information workers uses their employee intranet portal. This vital resource is in the flow of daily work, particularly among Sales people and in the enterprise.
40% of information workers spend an hour or more per day creating documents. We spend huge amounts of time capturing knowledge and process in documents.
Whenever I think about big data, I can't help but think of beer – I have Dr. Eric Brewer to thank for that. Let me explain.
I've been doing a lot of big data inquiries and advisory consulting recently. For the most part, folks are just trying to figure out what it is. As I said in a previous post, the name is a misnomer – it is not just about big volume. In my upcoming report for CIOs, Expand Your Digital Horizon With Big Data, Boris Evelson and I present a definition of big data:
Big data: techniques and technologies that make handling data at extreme scale economical.
You may be less than impressed with the overly simplistic definition, but there is more than meets the eye. In the figure, Boris and I illustrate the four V's of extreme scale:
The point of this graphic is that if you just have high volume or velocity, then big data may not be appropriate. As characteristics accumulate, however, big data becomes attractive by way of cost. The two main drivers are volume and velocity, while variety and variability shift the curve. In other words, extreme scale is more economical, and more economical means more people do it, leading to more solutions, etc.
So what does this have to do with beer? I've given my four V's spiel to lots of people, but a few aren't satisfied, so I've been resorting to the CAP Theorem, which Dr. Brewer presented at conference back in 2000. I'll let you read the link for the details, but the theorem (proven by MIT) goes something like this: