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?
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.
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.
The most recent data cuts from Forrester’s North American Technographics® Customer Experience Online Survey, Q4 2010 of how more than 3,400 consumers interacted with customer service organizations in the last 12 months highlight some interesting trends:
For the first time, web self-service topped the phone channel as the communication channel most widely used by customers to interact with customer service organizations.
Consumers use the phone channel 50% of the time. However, other channels are more widely used than the voice channel: 58% of the time, consumers search for an answer on the Web; 61% of the time they send an email to customer service; and 66% of the time they search a company’s FAQ.
Social channels are used for customer service, but numbers are very low (1% of customers used Twitter, but 6% of customers used forums).
Live-assist communication channels (phone, chat, cobrowse) have much higher satisfaction ratings than asynchronous electronic channels (email, web self-service). Satisfaction ratings are: phone (74%), chat (69%), cobrowse (78%), email (54%), and web self-service (47%).
To succeed in today's turbulent business environment, enterprises must drive deeper customer engagement, connecting empowered customers to the valuable services they want across multiple touchpoints. This crucial shift to an outside-in focus, however, brings new demands and challenges to the application development and delivery organization. On June 13, 2011, Forrester convened a group of expert analysts to discuss:
How application delivery should partner with marketing to drive deeper customer engagement through the entire life cycle across multiple touchpoints.
Best practices for application development to design and deliver improved customer experiences.
How to reconcile the need for stronger design with agile processes and continuous delivery.
How to optimize your mobile application strategy to serve empowered customers.
How to exploit emerging application platforms, including cloud, to empower customers and the business to enable rapid change.
The past few years haven’t been kind to software developers. Having the equivalent of a US master’s in computer science and having spent the first 20+ years of my professional life developing mission-critical software products and applications, I have had a hard time adjusting to the idea that developing software applications is a cost to avoid or a waste of time for many CIOs and application development leaders. It seems to me that we have been giving more emphasis to contracts, legal issues, SLAs, and governance concerns but forgetting about how IT can really make a difference – through software development.
Nevertheless, outsourcing kept increasing, and packaged apps exploded onto the scene, and software developers “outplaced” from enterprises. People started to believe they could get more value and good-quality software cheaper…but could they really?
With BT, digitalization, and customer centricity exploding, today is the perfect moment for application development leaders to review their application development sourcing strategy and align it to their BT strategy.
Why? Many reasons, including:
Software is the most important enabling technology for business innovation.
Clients use software every day. It’s become part of their life, and they enjoy the experience. Better software makes a better experience.
Lack Of Infrastructure Portability Is A Showstopper For Me
Salesforce.com bills Force.com as "The leading cloud platform for business apps." It is definitely not for me, though. The showstopper: infrastructure portability. If I develop an application using the Apex programming language, I can only run in the Force.com "cloud" infrastructure.
Don't Lock Me In
Q: What is worse than being locked-in to a particular operating system?
A: Being locked-in to hardware!
In The Era Of Cloud Computing, Infrastructure Portability (IP) Is A Key Requirement For Application Developers
Unless there is a compelling reason to justify hardware lock-in, make sure you choose a cloud development platform that offers infrastructure portability; otherwise, your app will be like a one-cable-television-company town.
Bottom line: Your intellectual property (IP) should have infrastructure portability (IP).