About Agility

May was definitely UX month at OutSystems! During our yearly user conference, attendees from around the world participated in dozens of sessions to define and discuss the quality of Great Apps and what it takes to create them. Usability expert Steve Krug, author of "Don't Make me Think," and "Rocket Surgery Made Easy," gave a talk and workshops around the importance of user testing. Version 8 of the OutSystems Platform was unveiled, showcasing the addition of a powerful new user interface editor in the IDE that simplifies the creation of highly usable interfaces, as well as other change management and operational enhancements.

But Why Usability? Why User Experience?

The difference between helping enterprises release applications into production and enabling them to create powerful applications that are widely adopted is based on their usability and user experience. This year's conference was about understanding the power of the Great App in the modern workplace.

It is clear that since the early 2000s Apple has raised the bar on user experience. The mass adoption of their products proved there was genuine demand for it and since then, everything about the way people expect to experience technology has changed. This is known as the consumerization of IT and is itself the topic of discussion at events like this year's CITE 2013.

All of this is only to say that...

User Experience Has Become a Corporate Asset

A corporate asset the same way real estate, intellectual property, and brand identity are. At this point in time most enterprises have been, at least, socialized to this idea. With mobile proliferation worth billions of dollars and BYOD projections equaling billions more, people are bringing their high tech devices to work with the EXPECTATION that enterprise applications will at least work as well as what they use at home.

So, as we've written often in this blog, if IT wants to stay relevant to their organizations, they are going to need to not only respond to user needs, but proactively cater to them. If they want to extend applications to the boundaries where workers exist, and if they are interested in delivering enterprise apps to mobile devices, and also have them adopted by users, then they are going to have to scale their UX strategy.

The benefits to business are too valuable not to! The cost savings alone are enough to justify implementing formal usability concerns. According to the IEEE, 15% of all projects are abandoned, and of the top twelve reasons projects fail, three are directly related to not getting user experience right. Whether it's bad usability testing, user centered design, or project management, getting user experience in-house and under control is as imperative today as extending brand identity.

But How Can Organizations Get IT Developers to Begin Thinking About Design?

Developers will not have time to become usability experts, nor should they. However, it's still important for them to learn some basic concepts in order to make an application better.

For starters, IT developers and software engineers could start by learning more about user centered design. In fact, it's imperative that developers understand the key concepts behind usability and the value those principles will bring to their apps.

From there it's also important to know that successful applications have 3 key characteristics:

• They are high quality (work with no bugs)
• They are high performance (work as fast as possible)
• They are highly usability (easy to work with)

Although quality and performance should already be part of any developer's checklist, usability is something relatively new and not natural for a developer. However it is key to user adoption and therefore shouldn't be dismissed, but embraced!

So Why Do IT Teams Tend To Jump Over Usability?

Two reasons:

1. They believe that adding usability concerns to their projects will considerably extend their project's duration, and they are already struggling with time.
2. They don't have in-house resources, and hiring external usability consultants is considered too expensive

The problem with this line of thinking is that there's nothing worse than delivering a business application and realizing that users won't adopt it because it isn't usable. By making certain developers are the first in line to think and worry about the usability of applications - preferably while developing - IT departments will be setting the path for higher user adoption rates at lower costs. So, while developing an application, your IT team should understand two points:

1. Regarding costs, applications don't have to be developed to 100% usability. Investments can be made to those parts of the application that are used 80% of the time, or areas that present serious UX problems. Low cost usability testing is also available, as described in Krugs', "Rocket Surgery Made Easy."
2. To help your team with resources necessary to continue on this journey, we have developed a "UX-for-IT" initiative that includes a toolkit that was especially designed to help IT departments adopt and scale their UX strategies. It contains an eBook outlining 11 usability principles for developers, along with examples. There's also a Vision Document Template, useful in helping IT teams understand and collaborate with their users when they begin building applications. We also included an easy to use UX checklist for aligning the build process to best practices.

There is no reason not to think about usability. Application development without user adoption as the ultimate goal is simply wasted effort. With usability considered from the beginning, IT departments can ensure that the efforts they are making are applied to the businesses needs.

This year our NextStep user conference was all about creating great user experiences on enterprise web and mobile applications, and we were pleased to host usability guru Steve Krug to the speaker line-up as keynote. 

Over several days Steve spoke and led workshops for hundreds of participants.

Steve is perhaps best known as the author of Don't Make Me Think: A Common Sense Approach to Web Usability.  This book has more than 350,000 copies in print and is in it's second edition.  His latest book is the usability testing handbook, Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems.

Both books are based on the 20-plus years Steve has spent as a usability consultant for a wide variety of clients, including Apple, Bloomberg.com, Lexus.com, NPR, the International Monetary Fund, and others.  His consulting firm, Advanced Common Sense ("just me and a few well-placed mirrors"), is based in Chestnut Hill, MA.  Steve spends most of his time teaching usability workshops, consulting, and watching old episodes of "Law and Order".

During the conference we had an opportunity to sit down with Steve to discuss industry trends and such.  The following are some highlights from that discussion:

Michel Ozzello: What are a couple of things every technology company can do to make usability more central to their development - and if they are not already doing that, why do you think that is the case?

Steve Krug: I think there are basically two routes to boosting the amount of commitment to usability. Either (a) get a powerful advocate somewhere very close to the top of the corporate ladder who decides that usability is going to be part of everyone's job and allocates the time and budget to make it happen, or (b) start small and grow virally. The second case is the one that interests me the most, because it's the one that almost anyone who believes in the value of usability can have a hand in. (You can always try to convince management to drink the user experience Kool-Aid, but I think it's usually something they have to discover on their own.)

I have to admit that I'm one of those guys who own a hammer so everything looks like a nail to me: I think that the best way to "infect" an organization with the UX bug is by getting as many people as possible to watch some live usability tests - even one or two.

A lot of the people I know who run usability tests for a living talk about it as a conversion experience: people watching their first usability tests often just suddenly "get it" that (a) regardless of what they thought before, all users are not like them, and (b) people have a much harder time figuring out how to use things than we like to think (i.e., they spend a lot of time just muddling through). So all of a sudden, it becomes clear that to produce something that people will enjoy using (and something that doesn't generate tons of frustration and support calls), we have to invest a lot more care, thought, and testing into the design of the things we build.

Why do I think most companies still don't pay enough attention to creating good user experience? I guess there have always been a lot of reasons. For instance, historically you've always been much more likely to get fired for shipping a product that's buggy or lacking crucial features than one that frustrates people. And UX research (e.g. usability testing) always had a reputation for being expensive and potentially slowing down development, although I think that's changing as people realize that lighter weight "guerilla" methods can be just as effective. Also, usability is a relatively new concept for a lot of people, so it's never been an indispensable line-item in development budgets. Who knows? Maybe it'll achieve that status in the next few years--mostly thanks to the influence of Apple.

MOZ: How do you see the discipline of Usability trending in the next few years?  What is going to matter?

KRUG: I think--or at least I hope--that it's going to become much less of a thing that only specialists do and more something that everyone does. For instance, I think that any degree program for developers or designers should include a course in user experience (I think most people could learn what they need to know in a semester). Not that there won't be plenty of work for specialists, just that they'll be doing more advanced work, coming up with new interaction ideas, and teaching everyone else.

MOZ: Tell us about Rocket Surgery Made Easy. Is a handbook for usability testing important today? At this point in the evolution of the web, do you find that people are still getting usability wrong?

KRUG: Well, we're back to me and my hammer again: I think that everyone who's building something that people interact with should be doing some form of usability testing, whether it's bringing in a few people once a month or just doing frequent "hallway" tests where you grab somebody for a few minutes and ask them to try using whatever you're working on at the moment. I mainly wrote Rocket Surgery for people who want to do some usability testing even though it's not their "real" job. So I spelled out a complete formula for how to do testing that's quick and efficient, but still almost always produces more valuable design insights than you can use.

And it's not so much that people are getting usability wrong; it's more that it's almost impossible to get all of usability right, at least on the first try. It's really hard, and with possible exception of the occasional genius designer (one of those unicorns people are always trying to recruit, like designers who code and developers who design), nobody can get it completely right without doing some usability testing.

MOZ: What have been some of your takeaways from the OutSystems conference?

KRUG:To name just a few:

• People in Lisbon are really nice and smart.  I already knew this from a previous visit, but it was fun to learn it all over again.
• I never realized that almost all the developers coding enterprise applications have to do their own design work.
• I didn't know there was a company out there that took my books as seriously as the folks at OutSystems. It was really gratifying to see what can happen when an organization makes usability a top priority.
• I loved some of the usability features they "cooked" into Platform 8. My favorite is probably the way they found to "automate" optimal vertical spacing in designs. I started out as a typesetter originally, so vertical spacing (or "leading") has always been an obsession for me, and I know just how much of a difference it can make for readers/users, and how hard it can be for even designers to get right. So I was really tickled to see that they'd come up with a feature that just does the right thing, without the person building the app having to think about it at all. Honestly, I was blown away by it.
• Also, some folks at OutSystems put together an excellent PDF called "11 Usability Rules for IT Developers" that has some of the best basic usability advice I've ever seen. 

Visit our conference site to watch Steve deliver his presentation to attendees, and check out this real-time, hand-illustrated infographic from our event last week.  Our UX-for-IT tool kit is also available for all developers interested in learning more about usability and UX basics.

In today's information-centric world, as web applications become more widespread and increasingly transactional, more and more corporate data and business logic are at risk. It has become necessary - in a way it's never been before - to ensure that every single line does not introduce a vulnerability and that every single software application - whether built for desktop, cloud or mobile -- is safe from cyber-attacks and that your intellectual property, customer data (credit card numbers, SSN, addresses, etc.), business processes and trade secrets are protected.

With so much at risk - money, reputation, legal issues - organizations today agree that application security is a top concern. In some businesses specific regulation exists, like PCI DSS, for payment cards cardholder information handling.  This regulation requires compliance to well-defined security standards as an imperative to conducting business.

Security must be accounted for at all layers - from network to application software. It takes a single unsecure pathway to private information to make an entire system vulnerable! The goal, of course, is to eliminate exploitable security risks in software at the application code level and ensure that all pathways to data are secure, and no vulnerabilities would allow a website to be abused for the purposes of spreading malware.

Hackers are known to be ingenious in discovering new entry points along these pathways. They started years ago at the network and hardware levels, but since firewalls and other network devices have closed many gaps, they are now going directly to the application layer.

This means that code security is key to ensuring secure applications, but as everyone in the development space knows, the gulf between development and security is not easily bridged.  This is unfortunate as it's more effective - not to mention cheaper - to solve security problems during the development phase of a project.  According to an NIST study, the cost of fixing security issues in software increases substantially further along the Software Development Lifecycle (SDLC) to the point that it costs 30x more to fix security issues after a breach in production than to build security into your code at the beginning of software design.

One way organizations are driving their security efforts is through the use of security testing tools to identify all potentially exploitable vulnerabilities in software at the application code level. Developers and security experts then team up to review these (usually very extensive) vulnerability lists, and fix those that the team agrees should be addressed, according to occurrence frequency, exploit complexity, and potential impact. These reviews require a huge amount of effort - in time, resources, and expertise - and they need to be undertaken every time an organization needs to deploy a new and secure release of an application.

With the release of the latest version of the OutSystems Platform, things are a bit different. For the past decade, results from every security test - code vulnerability scans, runtime analysis scans, penetration tests - that customers have performed on code generated by our platform have been incorporated back into the platform.  That is ten years of accumulated intelligence and improved security. Ten years of security testing ... all that knowledge accumulated over the years instantly made available to developers from the moment they begin developing a new application. It's all in the platform and is an inherent part of every application every customer deploys.

Taking our approach to application security one step further, we've recently integrated a security testing tool - HP Fortify Static Code Analyzer - directly into our quality assurance process. By making this security review a part of our product delivery processes, and by enforcing an aggressive acceptance criteria (no critical, no high, no medium reported occurrence left behind) we are able to systematically ensure that the applications generated with the OutSystems Platform - both Java and .NET applications - are inherently secure. When it comes to code vulnerabilities, fix once, fixed forever.

Continuous monitoring and improvement of our platform - along with regular client feedback and regular vulnerability updates from HP - means that application security grows stronger with every iteration.

It's like having a security expert in-a-box. Even if your developers don't have the knowledge or the time to properly address code security, your applications are designed and built as if they were developed by security experts. That's one less NFR (non-functional requirement) you need to worry about. 

Earlier this year we posted an article about IT 'failures' and discussed why inefficiency in most IT departments was really due to the cost of changing and maintaining existing applications.  This cost results in ever-increasing backlogs and an increase in technical debt.

In this post, let's take a closer look at the current approaches most IT departments are using to solve their backlogs and why those approaches correlate directly with IT's inability to respond to business requests.

At first glance it stands out that the way companies currently deal with their backlogs and technical debt is just not working.  Too many IT departments are challenged with unsustainable business models that render them ineffective, or in some cases, irrelevant.  They are in danger of being relegated to little more than cost centers.  And in that state, they are unable to support companies hoping to differentiate through innovative tech.

This is unfortunate because most IT departments are probably doing the best they can.  The problem is simply that current techniques and tools used for delivering and maintaining enterprise systems are hard to use, and the applications these tools deliver are hard to maintain.  This context creates an expensive and unmaintainable problem. 

Today, when a business unit needs a new application, or a new piece of functionality in an existing application, your typical IT department responds in one of four ways.  At best these approaches kick the can down the road. At worst, they add to the problem by creating an architecture and technical environment that will be unresponsive and unable to adapt to changing business needs. 

Let's look at current approaches to software change:

1. Buy, and Customize, a Packaged Application.

Consequence: When an organization chooses to buy a packaged application such as SAP or other ERP, payroll or CRM solutions, they are buying into pre-defined functionality that delivers best of breed standard processes for the industry/market it serves. More often than not, organizations find that their processes are somewhat different from what the package offers, and therefore must customize the package. The problem is that packages have not been built for change and customizing packaged applications is hard, expensive, can require hundreds or thousands of consulting hours, and will create a maintenance nightmare that possibly hinders future package upgrades.

2. Build a Custom Solution Using In-house Developers or System Integrators.

Consequence: The problem with this approach is that building a large system using the current state of techniques and tools is complex and expensive.  In many situations, the organizations then fall hostage to the system integrators who built the application, because they are the only ones that know how to maintain it. In any case, enterprise applications are never "built for change".  The urgency and focus on getting an application deployed, using current techniques, produces a solution that is not easy to change, and is often prone to break when you do.  This just ends up being a big add-on to existing technical debt.

3. Select and 'Rent' a Cloud-based Solution (SaaS).

Consequence: With the advent of software-as-a-service (SaaS), companies are resorting more and more to 'renting' cloud-based applications to satisfy business requirements. By the very nature of the model, SaaS applications offer small degrees of parameterization, and with the exception of a couple of very large vendors, no customization options. To a degree, this is a blessing in that IT tends to use SaaS "as-is" and therefore limits maintenance requirements. It does not, however, address the requirement for custom functionality - namely interfaces, workflows and data repositories that are unique to nearly every organization.

4. Do Nothing!

Consequence: When budget, time or resources are not available to buy or build the needed application, IT often just says "No" to the business. When the IT department chooses to do nothing, it causes its relevance to decrease even further and results in the creation of...

Shadow IT

When the pressure to come up with a solution for the business is intense, and IT can't deliver what is needed, business teams often decide to take matters into their own hands. This is commonly known as "shadow IT" - applications built, installed or rented outside of IT's control. Typical approaches include using departmental 'wiz kids' or finding hired guns to solve the problem.  They may use platforms such as force.com or SharePoint to develop and deliver an application to solve the business problem. Or they may use portal, workflow or collaboration tools - or even deliver completely bespoke applications, built using any number of tools or languages.

With cloud-based offerings delivered as a 'service', the business does not necessarily need to involve IT at all - there is nothing to install, nothing to back-up, no disaster recovery considerations, data conversion can be outsourced - business can solve the problem without IT even knowing the application exists.   

However, as these applications are adopted and begin to grow, the complexity of changing them and/or the inherent value of the data being maintained by them, forces the business to turn control of the applications over to IT.

Looking at these approaches dealing with backlogs, one can see that none of them are particularly desirable and they are replete with cost issues, control issues, and scalability issues. Yet, despite their futility, time and again, organizations continue to walk down the same trodden paths expecting to arrive somewhere different - or maybe they feel like there is no other path to take?

The fact is there's always a new trail to blaze.  In an ideal world, you would not have to worry about the cost of change. You would simply focus on delivering the application your business needs, and know that it would only slightly increase your maintenance costs. In order to do that, you'd need to use technology and an approach that could ensure a flat cost of change across the entire lifecycle of your applications.

In a future post, we'll examine how these same approaches, when thought of differently, can be made to improve IT productivity and the ability to support business innovation.  In the meanwhile, for those interested in reading more about what holds IT back from innovation, download our featured white paper on the struggles of IT to innovate.

Whenever anybody says Functional Requirement, I think of princesses. I think of Ariel and Cinderella. I think of how each is central to her story and embodies a specific identity, and then I think of the princess who stands out as a true metaphor for functional requirements - the one who reflects the role perfectly. I think of Snow White.

Snow White is a functional requirement if I ever saw one. She is at once central to her story, its main protagonist, its raison d'etre, yet surrounded by a host of supporting characters - dwarfs - whose roles are necessary for the story to be complete.  No dwarfs, no real story. It's that simple. If a single dwarf is missing, the entire story is compromised. Snow White is compromised.

And it's nearly the same with applications. If an application is the story and Snow White is the functional requirement, then we can think of dwarfs as non- functional requirements (NFRs). If a single NFR is missing from an application then that application is compromised. Deploying a squirrely application is the same as adding maintenance issues and technical debt directly to your application portfolio. Eventually, that application will have to be addressed, those NFRs will have to be added, and the IT department who deployed the app will have to contend with the cost of changing software.

How does this happen? Changing and maintaining software is hard and therefore expensive to do and IT departments are often rushed or underfunded. However, if they are in a 'Just do it' mode then those operational, non-functional requirements that make an application complete are easy to leave out or are 'forgotten.' The consequences of leaving these NFRs out of an application lead directly to the aforementioned maintenance problems and increased technical debt.    

Here's the list of most common NFRs that we see our customers worrying about:

1. Maintainability The ease with which the system can be changed, whether for bug fixes or to add new functionality. This is important because a large chunk of the IT budget is spent on maintenance. The more maintainable a system is, the lower the total cost of ownership will be.	2. Portability The ease with which software can be installed on all necessary platforms and the platforms on which it is expected to run.
3. Reliability The capability of the software to maintain its performance over time. Unreliable software fails frequently, and certain tasks are more sensitive to failure (for example, because they cannot be restarted, or because they must be run at a certain time).	4. Scalability Software that is scalable has the ability to handle a wide variety of system configuration sizes. The nonfunctional requirements should specify the ways in which the system may be expected to scale up (by increasing hardware capacity, adding machines, etc.). Scalability ensures usability for five users or five thousand.
5. Flexibility If the organization intends to increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system. Flexibility is the ease with which the system can be reused, deployed, and tested.	6. Auditability When something goes wrong, you need to understand the root cause of it. So it is normal that auditability is a common NFR. The problem is that you hardly remember to have all the checkpoints in the process, all the exceptions logged, and to ensure that the subsystem to support it does not interfere with your application performance.
7. Documentation It's hard to keep complex system documentation up to date. Even if you're able to document the initial version of your application, by the time you've finished, the application has changed and its documentation is outdated.	8. Performance The performance constraints specify the timing characteristics of the software. Certain tasks or features are more time-sensitive than others; the nonfunctional requirements should identify those software functions that have constraints on their performance.
9. Security Integrity requirements define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software.	10. Usability Usability relates to how easily users can learn how to use a system and how efficient they are while using it. Highly usable systems reduce the effort required to read or input data and prevent users from making errors resulting in increased operational efficiency.

Like Snow White's dwarfs these NFRs are necessary to completing the story of the application. While you might consider 2 or 3 important NFRs for a project (like performance and security), you'll probably not cover the others extensively enough, or you might miss out on them all together.

And if you do allocate time to deal with them all, when the project schedule slips, the NFRs may be the first thing you'll drop... because no one really sees them, and your team will be looking at the functional requirements instead.

So, whether you plan for NFRs or not, chances are high you won't cover them 100% of the time in your development project. You'll compromise and not think of the whole story - the whole application. 

But you should try. You should try to avoid adding technical debt and maintenance nightmares to your future portfolio whenever possible. The cost of change is real, and the moment you deploy your app, you'll have to address its problems. 

From your experience what are the NFRs you constantly see developers and project teams dropping most often?

Mobile applications have become a recurring topic everywhere we turn.

Our customers' IT departments are being pushed by their business units to create all sorts of mobile interfaces. If you look at the application backlogs at most IT departments, you'll find more than a couple requests for something mobile.

Most of those requests include extending existing legacy systems to provide mobile interfaces that can be used by customers, partners or employees.

If you're about to leap into the mobile world and need to provide unique capabilities that are extensions to existing systems, you probably have big plans to customize or upgrade those systems to enable mobile access.  If this is the case - Read on before you Leap!

Or consider this an intervention.

So your business says they want mobile; they have to have mobile!  We understand.  The growth in mobile app usage and the prevalence of mobile phones and tablets in the workplace (and all the BYOD frenzy that everyone is writing about) makes having mobile a necessity and also an opportunity to increase worker productivity.

Think about maintenance before you start:

Please consider this before beginning a mobile adventure-- the cost of customizing your legacy systems to implement mobile will grow exponentially year after year.  It will eventually create a maintenance nightmare and may even hinder future product upgrades. The older and more monolithic the legacy system, the larger the maintenance problems will be.

The cause for this is simple: mobile applications require a level of flexibility and a pace of change that is completely different from the pace of change of your legacy system. For a mobile application to work and be adopted, you'll need to focus most of your energy on delivering a great user experience (UX). No matter how many usability tests you do, one thing is certain: when the app is rolled out to your users, you'll discover a lot more changes that need to happen in order to provide a better UX. What this means is that you'll need to have the ability to quickly adapt your application (to change it's interface or even business logic) and redeploy a new version of it, so it can be in the hands of users for another round of validation. This level of flexibility and adaptation is something that simply doesn't exist in the world of legacy systems.

Two additional items to consider that can make or break you endeavor are performance and security.  If you're extending a legacy system that is used by 100 people and all of a sudden make it accessible to 1000, you'll definitely hit a scale problem and you'll see performance go down (of both the original system and the new mobile interface).

In terms of security, besides the obvious user access considerations, you need to think about your data. All of a sudden, the data that was stored inside that old legacy system behind that firewall becomes available on the mobile devices of your users.   This leads to architecture choice.  And if you decided to go for a native application approach, it is more likely that some of that your data will be stored in the user's phone! When we consider the number of phones that are lost or stolen every year, the risk of information leakage gets really frightening.

Keep your legacy safe:

Instead of heading down a path that will increase your technical debt and induce performance/security related heart-burn, consider stabilizing your legacy systems - that is, don't change them. Leave them alone!

Leaving your legacy systems intact allows you to keep the value you have built into them over the years without the risk of "breaking" them, and you will keep the maintenance and operational costs stable. They were built to last, so don't try to change them!

If you got to this point, then you're ready to start thinking about extending your legacy with a mobile layer. 

Build a mobile layer that's prepared to change:

With your legacy system untouched and stabilized where it should be, you can start thinking about extending it.

The approach is relatively straightforward (although not simple):

1. Leverage your system's APIs to access data and functionality, by creating a set of integration services that use those APIs and that provide caching, synchronization and security;
   
   
2. Create a set of business services that will be used to implement the business functionality in your mobile application;
   
   
3. Focus on designing highly usable mobile interfaces that will lead to high user adoption.

By doing 1 and 2 you'll be creating an important foundation of software components that can be reused in other applications. That will set the base for a Service Oriented Architecture (SOA) that you can then grow to leverage previous investments and deliver more applications faster and cheaper.

Step 3 requires some additional understanding of UX, and that's enough for an entire series of posts, so we'll leave it for another time.

The ultimate trick to make this all work is to ensure that, whatever you're building, it needs to be extremely flexible and ready change.

Examples from the real world:

It always seems a long way form talking about it to actually making it happen, and the best way to really understand if this works is to see examples of how others have done it.

Last week we ran a webinar with our partner Conigent, where they took the audience through the case study of a mobile application they built for Sheetz, that extended their ERP, built in record time with the Agile Platform.

In the words of Ameet Shah, Conigent CEO, "We were able to deliver highly differentiating applications at record speed, without modifying source code of the ERP application and all the while we were doing this while maintaining quality and preventing ourselves to ever refer to these applications as legacy applications".

For the full story check out the recorded webinar here. 

Considering a New York Times Bits Blog article stating that enterprise-wide, IT spending will be $2.68 trillion in 2013, one would think the IT industry - with all its engineering nerd-brain powers - would be at the forefront of efficiency and automation.  Curiously, this is not the case.  Not even by a long shot.  Not even remotely.  Not even ... well, you get the picture!

And if what Gartner writes is true, then 80% to 85% of an IT department's budget is used simply to Keep The Lights On (KTLO). 

Let's allow these numbers to sink in appropriately, shall we: At least $2.68 TRILLION IN TOTAL SPENDING and 80% to 85% of IT BUDGETS USED ON WHAT IS ESSENTIALLY MAINTENANCE?  That sounds like a winner to me!  How many more zeroes can KTLO have?

All this money going to maintenance actually creates a second rail of inefficiency - a pileup of new requests made by the business that IT cannot deliver. This is the IT department's backlog and is no small matter. It indicates lost productivity, an inability to innovate and the reflection of an IT department misaligned with its core business. 

It is not merely a fact of functionality requests being stuck in a rut and arriving late that is the problem here.  Here's another industry stat attributed to Gartner: the backlog in most IT departments is actually compounding annually at a rate of 10% to 20% - meaning in the worst cases, a company's backlog could double in five years!

So, to recap: trillions of dollars in spending, most of it going to maintenance, and an ever-increasing backlog. 

Could it get worse?

Here's the hat-trick!  Any attempts to bring this backlog under control will bring with it a cost, the value of which is added to the KTLO. If an organization attempts to tackle its backlog by building apps in a fast and furious manner, it makes compromises that impact future IT debt.  The conundrum is simple: IT departments can implement change requests quickly and create greater IT debt, or they can take their time, not empty their backlog fast enough and be accused of being unresponsive to the core business.  Any attempt to fix the inefficiency problem potentially adds to it.  Technical debt grows.  Backlogs get bigger.  IT is eventually left behind, unable to react to the needs of business.

Spend money. Lose ground. Disappoint management.  Fail. Fail. And Fail.

Given the exorbitant amount of ducats in play, why would any organization close their eyes to so much wasted productivity and spending?  Why would any organization continue along the same path expecting something different? 

The way companies are currently dealing with their backlogs and technical debt is not working.  It is an unsustainable business model that will render IT departments ineffectual and in danger of collapsing under their own weight.

This failure is not entirely IT's fault.  In fact IT departments are probably doing the best they can.  The problem is simply that maintaining enterprise systems is extremely hard and therefore expensive.

The bigger and older the system is that needs to change, the more complex and costly that change will be. We all know how hard it is to reverse engineer thousands of lines of code to find the exact places where we need to apply the changes. And how hard it is to validate the impact of those changes across all application and system dependencies. And even when changes are ready and tested, how hard it is to deploy a new version into production.

Unless we solve the problem of the cost of change, we will not be able to reverse this downward spiral that is causing IT to fail miserably.

I'd make a suggestion, but this isn't a sales pitch.  It's only the IT equivalent of a Public Service Announcement.  An eye opening piece, really.

Happy Spending in 2013!

I got to listen to a replay of the CIO Power Panel from NextStep 2012 recently, and found a gold nugget around the role of Business Analysts in an Agile development approach.

The panel was moderated by OutSystems CEO Paulo Rosado and had CxOs from four different companies chiming in on how agile works in their shops and the impact of business analysts on their processes.

From 'Catarinas' to huge project failures, this was a colorful debate. So if you are wondering how to make agile work in your enterprise application development process, take 15 minutes to listen to this snippet from the discussion.

You can hear the 15 minute segment here.