Front-end developers are getting the short end of the stick: they're either considered not technical enough to be a developer or too technical to be considered a designer/engineer. This conflict resonates further into the organization and stakeholders aren't in agreement on where front-end developers should sit---with the BT organization or within the business. Both sides make compelling arguments as to why front-end devs should sit within their respective parts of the organization. Our recent developer survey tells us that 47% of developers sit within a single centralized BT organization.
The main reasons BT organization argues three reasons front-end developers should sit within BT:
To make sure that development standards are consistent.
It ensures that they work in sync with the back-end team.
Front-end devs work with code and BT should have ownership of anything related to code.
On the other hand, marketing argues that front-end developers (also referred to as designers/web developers) are better suited for marketing since:
Front-end devs can create rapid prototypes for customers to see their ideas conceptualized, but it’s not intended to be production-ready at all.
BT organization moves too slowly and is unable to deliver the changes needed to enhance the customer journey at the speed it requires.
The modern business world echoes with the sound of time-tested business models being shattered by digital upstarts, while the rate of disruption is accelerating. Organizations that will win in this world must hone their ability to deliver high-value experiences, based on high quality software with very short refresh cycles. Customers are driving this shift; every experience raises their expectations and their choices are no longer limited. Like trust, loyalty takes years to build and only a moment to lose. The threat is existential: Organizations need to drive innovation and disrupt their competitors or they will cease to exist.
Very much in the shadows of all the press coverage and hysteria attendant on emerging cloud architectures and customer-facing systems of engagement are the nitty-gritty operational details that lurk like monsters in the swamp of legacy infrastructure, and some of them have teeth. And sometimes these teeth can really take a bite out of the posterior of an unprepared organization.
One of those toothy animals that I&O groups are increasingly encountering in their landscapes is the problem of what to do with Windows Server 2003 (WS2003). It turns out there are still approximately 11 million WS2003 systems running today, with another 10+ million instances running as VM guests. Overall, possibly more than 22 million OS images and a ton of hardware that will need replacing and upgrading. And increasing numbers of organizations have finally begun to take seriously the fact that Microsoft is really going to end support and updates as of July 2015.
Based on the conversations I have been having with our clients, the typical I&O group that is now scrambling to come up with a plan has not been willfully negligent, nor are they stupid. Usually WS2003 servers are legacy servers, quietly running some mature piece of code, often in satellite locations or in the shops of acquired companies. The workloads are a mix of ISV and bespoke code, but it is often a LOB-specific application, with the run-of-the-mill collaboration, infrastructure servers and, etc. having long since migrated to newer platforms. A surprising number of clients have told me that they have identified the servers, but not always the applications or the business owners – often a complex task for an old resource in a large company.
Developers And Their Business Counterparts Are Caught In A Trap
They swim in game-changing new technologies that can access more than a billion hyperconnected customers, but they struggle to design and develop applications that delight customers and dazzle shareholders with annuity-like streams of revenue. The challenge isn’t application development; app developers can ingest and use new technologies as fast as they come. The challenge is that developers are stuck in a design paradigm that reduces app design to making functionality and content decisions based on a few defined customer personas or segments.
Personas Are Sorely Insufficient
How could there be anything wrong with this conventional design paradigm? Functionality? Check. Content? Check. Customer personas? Ah — herein lies the problem. These aggregate representations of your customers can prove valuable when designing apps and are supposedly the state of the art when it comes to customer experience and app design, but personas are blind to the needs of the individual user. Personas were fine in 1999 and maybe even in 2009 — but no longer, because we live in a world of 7 billion “me”s. Customers increasingly expect and deserve to a have a personal relationship with the hundreds of brands in their lives. Companies that increasingly ratchet up individual experience will succeed. Those that don’t will increasingly become strangers to their customers.
What a strange summer this has been! From Boston to London to Paris to Turin, the weather has offered weekly and even daily reversals, with continuous change from sun to rain, from hot and damp to cool and crisp. I missed a nice spring season. Even today, from 35º-38º Celsius (95º-100º Fahrenheit), we just went to 22º Celsius (71º Fahrenheit) with a perfect storm! A continuous climate and sudden change is quite unusual in some of these countries. Certainly it is where the Azores Anticyclone usually dominates from mid-late June to mid-late August, offering a stable summer. How many times have you had to change plans because you discover weather is about to change!?
You might be thinking, "What does this have to do with this AD&D blog?" It’s about change! I am wondering if, in our daily lives, getting used to unexpected conditions and having to handle continuous change favors a mindset where change is just something we have to deal with and not fight. A new mindset very much needed given the change we see ahead in how we develop, test, and deploy software!
My focus in this blog is testing, although the first change we need to get used to is that we can’t talk any longer about testing in an isolated fashion! Testing is getting more and more interconnected in a continuous feedback loop with development and deployment. (See my colleague Kurt Bittner's report on continuous delivery; I could not agree more with what Kurt says there!)
In the days when web applications were king, this type of insight was doable with simple web analytics and similar tools. Today, continual experience optimization is much more difficult because of:
Multiple interaction channels. You must collect, correlate, and analyze data in a coherent way across multiple channels of customer interaction. A single customer interaction may cross between channels or even use more than one channel at the same time.
Many back end servers. You must integrate data from multiple back end servers including recommendation engines, commerce, mobile application servers, digital asset management, community, collaboration, messaging, and more.
The need for rapid change. You must quickly change any or all of your digital experiences and back end services based on what you’ve learned.
The need for contextual experiences. You must use each individual customer’s context to dynamically adjust experiences in real-time.
I just finished my new report on the Agile testing tools landscape. I’ll point Forrester readers to it as soon as it publishes. But there are few things that have struck me since I took over the software quality and testing research coverage at Forrester and which I would like to share with you in this preview of my findings of the testing tools landscape doc.
My research focus area was initially on software development life cycles (SDLCs) with a main focus on Agile and Lean. In fact, my main contribution in the past 12 months has been to the Forrester Agile and Lean playbook, where all my testing research has also focused. Among other reasons, I took the testing research area because testing was becoming more and more a discipline for software developers. So it all made sense for me to extend my software development research focus with testing. But I was not sure how deep testing was really going to integrate with development. My concern was that I’d have to spend too much time on the traditional testing standards, processes, and practices and little on new and more advanced development and testing practices. After 12 months, I am happy to say that it was the right bet! My published recent research shows the shift testing is making, and so does the testing tool landscape document, and here is why:
Google sets amazing new standards when it comes to web, mobile, and cloud technologies. That's why we are here at Google I/O 2013 in San Fransciso to find out what new technologies and tools developers can expect on all technology fronts. See this special edition of Forrester TechnoPolitics to experience the energy of Google I/O.
There is a scene in the Broadway hit Spamalot in which a peasant jumps up from a cart of corpses and vigorously complains that he's "not dead yet". It's a humorous side-story to the main theme of the search for the Holy Grail. One might be accused of thinking of COBOL in the same way, as a side-story to the current major themes of mobile and web development, or perhaps as a historical footnote to the current narrative. IBM's recent announcement of major upgrades to its COBOL compiler technology provides a good reason to pause in our headlong pursuit of the latest technology to reflect on the value of COBOL applications in enterprise software portfolios.
While mobile and web technologies often garner everyone’s attention, the reality is that most organizations that have been around for more than 30 years still run their core business processes using systems that were written in COBOL. Anything that makes these apps easier to evolve and extend is a very good thing. The reality is that evolution and extension of these apps is critical to business success. In order for the flashy-new-social-networking-enabled mobile and web Systems of Engagement to succeed, the workhorse Systems of Record and Systems of Operation are going to have to evolve apace. This means that they must take advantage of the latest architectures as well as being refactored and modularized to align with a service delivery model.
Banks have a reputation for being stodgy and conservative. But Credit Agricole (CA) has broken the stereotype. I had a great discussion a few weeks ago with Bernard Larrivière, Director of Innovation, and Emmanuel Methivier, the CA Store Manager, about the CA Store launched last fall. The store houses new services developed by third-party developers using the bank’s secure customer data — one small step for CA, one giant step for the banking industry and the data economy.
The CA Store was not only inspired by the Apple Store model but also by government open data initiatives. The public sector provided the model of exposing APIs to internal data and working with independent developers to encourage application creation. However, in a move that will likely be carefully watched by their public sector brethren, CA recognized the need for a better business model to incent developers to use the data, and to sustain the development and maintenance of the applications.