Development leaders! Project leaders and business analysts! Application and solution architects! Want to move forward on your business technology (BT) journey and be viewed by your business stakeholders as a valuable team member? Take a tip from last week's Forums held in Boston. Embrace Business Process Management (BPM) And Customer Experience. Don't ignore them, embrace them. Why? They're essential to helping you achieve your business outcomes.
I know, I know. You read the above and now think "Gee Kyle, what's next? Going to enlighten me on some new BPM or customer experience management technology that's going to transform my very existence, my company's future?"
Nope. Let me explain....
Last week we hosted more than 250 of your application development and delivery and business process peers in Boston and focused on how to succeed in the new world of customer engagement. The most impactful discussions I heard were the side conversations we held with attendees, sometimes occurring over dinner and cocktails. We didn't discuss technology. We discussed the skills your peers were developing in two fundamental areas:
BPM - no, not the technology but the Lean and Six Sigma based methods, techniques, and tools organizations use to focus on business processes and not functions; to strive for continuous improvement; and to focus on customer value.
Customer experience - defined more eloquently by my peer Harley Manning, but I'll summarize as the methods, techniques, and tools used to understand how customers perceive their interactions with your company.
Most Forrester readers certainly understand the importance of empowering their employees to contend with highly informed and increasingly demanding customers. But I’m often asked just how to overcome the process and data integrity challenges of apps or services that empower employees and/or drive continuity of experience for consumers across channels. With the rise of mobile as well as web and call center interactions and with a proliferation of new tools for managing distributed processes and data, most application development and delivery professionals as well as their business process and applications colleagues have to absorb all the arguments before they make decisions that could be critical to their firms’ futures – to say nothing of their own careers.
One pioneer whom I interviewed was immensely proud of his lightning rollout of a guerilla app to support his firm’s front office in advising clients on complex product choices. I asked him about future plans and sheepishly he admitted they would be starting again from scratch because the guerilla app was unable to leverage enterprise services exposing critical data about product offerings. He remarked ruefully that sometimes you do have to follow the IT standards “yellow brick road” rather than just head for the hills, but wouldn’t it be great to have the best of both worlds, with both agile deployment and full advantage taken of enterprise assets and data?
If you need a deeper understanding of the issues and options, then I’d like to invite you to join us at Forrester's Application Development & Delivery Forum, where my colleague Clay Richardson and I will discuss in practical terms how to deliver integrated experiences across multiple touchpoints.
Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.
This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.
Why Does This Work?
The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.
As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."
What is the definition of an "application"? We are "applications development and delivery professionals" - surely we have this question nailed, don't we? The question keeps coming up in different contexts, and since there are many potential opinions, a blog is the perfect place to spur debate. Here are some (simplistic) questions to generate debate:
Is a Web page an application?
If not, how many Web pages does it take until I consider it an application - 10, 100, 1,000?
Does size matter? (Please behave yourselves with this one.)
Is the size of the code base a pertinent factor?
What about SharePoint sites, Access databases, and spreadsheets? Are they applications?
Where do COTS and packaged apps fit?
Does the technology I use affect the definition?
If I use a scripting language for a quick-and-dirty task, is that an application?
Does SOA erode the definition of an application?
Do we cease thinking about applications as entities and think about them more as containers that hold collections of SOA services?
How does open source affect the definition?
How does my role affect my perception of an application?
Do developers and users use similar definitions?
I have my opinions - in fact I just finished a draft piece of research on it that will be published in January, but what are your opinions?
A quick note on a big announcement today by IBM that is being rolled out as I write this. No, I don't have a crystal ball - my colleague Brad Day and I spent a day in Poughkeepsie in late June for the full scoop - provided under NDA. The announcement is massive, so I'll just lay out the high points and a few of my thoughts on what it means to apps folks. I'll leave the deeper I&O/technical details to Brad and others in subsequent posts and research. My goal here is to get a conversation going here on what it may mean to apps people in your IT shops.
What's in the zEnterprise announcement?
It's a new computing environment that unifies Linux, AIX, and z/OS on a new server complex that includes mainframe servers, x86, and Power7 blades under a single set of management software: the zEnterprise Unified Resource Manager (URM).
A 10 Gb private data network joins the new z server (z196) and zBX - an ensemble that houses racks of x86 and Power7 blades. It also includes an intra-ensemble network that is physically isolated from all networks, switches, and routers - permitting removal of blade firewalls.
One client claims a 12-to-1 reduction in network hops by eliminating blade firewalls.
The z196 permits up to 96 Quad-core 5.02 ghz processors, 80 available for customer use, and 112 blades.
What is the impact on applications people and application-platform choice?
zEnterprise is a monster announcement that heralds a long laundry list of improvements - it would be impossible to cover all of the ramifications in a single blog post; however, a brief glimpse of some of the most notable improvements that affect applications folks include (zEnterprise as compared to z10):
Applications development people can't stand the Luddites in the operations group, and ops people hate those prima donas in apps dev - at least that's what we are led to believe. To explore the issue, two of my colleagues who write to the infrastructure and operations (I&O) role - Glenn O'Donnell and Evelyn (Hubbert) Oehrlich - invited me to participate in an experiment of sorts. They arranged a joint session for the I&O Forrester Leadership Board (FLB) meeting, and I was the sole applications guy in the room - a conduit for I&O FLB members to vent their frustration at their apps dev peers. For those who aren't aware, FLBs are communities of like-minded folks in the same role who meet several times a year to network, share their experiences, guide research, and address the issues that affect their role.
We infused the session with equal parts education, calls for joint strategic planning across all IT work, and a bit of stand-up comedy - Glenn noted that as representatives of our respective roles, he and I were actually twin sons of different mothers. I noted that in that context that our parents must have been really ugly. Once we opened the session for discussion, the good folks in the room wasted no time in launching verbal stones my way. Now, I'm no IT neophyte: I've been in the industry since 1982, and I'm no stranger to conflict - I grew up with 3 older brothers, and we all exchanged our fair share of abuse as siblings will. Still, I wasn't quite prepared for the venting that followed. To summarize a few of the main points, I&O sees apps folks as:
Recently, I discussed complexity with a banker working on measuring and managing complexity in a North American bank. His approach is very interesting: He found a way to operationalize complexity measurement and thus to provide concrete data to manage it. While I’m not in a position to disclose any more details, we also talked about the nature of complexity. In absence of any other definition of complexity, I offered a draft definition which I have assembled over time based on a number of “official” definitions. Complexity is the condition of:
OK, so the holidays are over, you've either closed, or are in the process of closing out 2009 year-end processing. The 2010 decade has begun, and it promises momentous change before we see the end of it: Leading edge technologies will become commonplace; Still newer technologies will emerge; New business threats and opportunities will arise; And the impact of the Baby Boomer phenomenon will finally arrive.