Archive for the ‘Enterprise Software’ Category
Only three options are available to you once your technical debt overwhelms the development and customer support teams:
- Continue as is.
- Start refactoring in earnest to pay back your debt.
- Switch to a new code base, either by launching an unencumbered development project or through acquiring new software from another company.
The first option, obviously, does not solve any problem – you simply continue a struggle that becomes more and more difficult over time. As indicated in the post Elbow Room for Handling Technical Debt, the second option is quite difficult to carry out if it is exercised at a late point in the software’s life cycle. This post examines the third option – starting afresh.
The attraction of starting afresh is always tempting. The sins of the past, hidden in layers over layers of technical debt and manifesting themselves in low customer satisfaction and poor customer retention, are (sort of) forgiven. The shiny new software holds the promise of better days to come.
Trouble is, your old sins are there to get you in three nasty ways:
- New technical debt: Even if the shiny new software is very good indeed, it will decay over time. Unless you transformed your software engineering practices to ensure refactoring is carried out on an ongoing basis, sooner or later you will accrue new technical debt.
- Migration: Good that the new software might be, it is not likely to provide all the functionality the old software had. Migrating your customers will require a lot of hard work, particularly if your customers developed elaborate business processes on top of your old software.
- Critical race between old and new: For a period of time (say a couple of years) the old software is likely to run alongside the new software. Any significant new regulatory requirement will force you to update both the old software and the new software. Ditto for security. Any nifty new technology you might want to embed in your new software is likely to be equally desirable to customers who still use your old software. You will be pressed to incorporate the new technology in the old software, not just in the new software.
Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:
For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.
Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.
You might be able to reduce the ‘150% for two years’ investment by applying some draconian migration measures. Such measures, of course, will affect your customers. In the final analysis, your decision to acquire new software must be viewed as the following simple question:
What value do you place on your customer base?!
Cutter Consortium has published the Executive Update entitled Open Source Software and Agile Software Development: Parallels and Lessons for Enterprise IT by Sebastian Hassinger (“Seb”) and me. Here is the abstract:
The phenomenon of open source software (OSS) is a recognized and mature aspect of the global IT market with profound implications for enterprise IT. A newer trend emerging is the various disciplines and methodologies that fall under the rubric of agile software development, which has a number of interesting parallels with and similarities to OSS. With the adoption en masse of OSS projects, such as Linux and Apache, by the mainstream enterprise customer, there is a track record of more than 10 years with which to gauge the extent and the nature of the impact on the enterprise. While agile has not yet reached the level of adoption that OSS enjoys, all indications are positive for that occurring in the near future. By examining its parallels with OSS, one can make inferences about the nature of the long-term potential impact of agile.
I am honored to co-publish with Seb!
(If you have not yet “e-met” Seb, here is his bio:
Sebastian Hassinger has worked in the IT industry for more than 25 years in large firms and as an entrepreneur. He founded two ISPs, helped launched several startups, and held senior strategy and business development roles with Apple, IBM, and Oracle. Mr. Hassinger created the first customer support Web site for Apple Computer. At IBM, he helped create a new business unit in the Tivoli subsidiary to address the needs of system management in the Internet era; worked on special projects for Tivoli’s CTO, including defining an Internet protocol for management of dynamic services; and was Senior Strategist for IBM’s Pervasive Computing initiative. At Oracle, Mr. Hassinger is Director of Market Development, where his specific responsibilities include developing the financial services market worldwide and the Asia-Pacific horizontal market. He holds MBAs from Columbia University and London Business School, is a published author, and holds more than a dozen software and business model patents. He can be reached at firstname.lastname@example.org).
Abstract: The presentation applies Agile thinking to critical aspects of strategy and execution at a time of uncertainty and disruption. The essential point is simple and logical: Agile values and principles are indivisible. To succeed, they must be applied not just to R&D, but also to customer and company, simultaneously. This requires reconfiguration of customer relationships, employee policy, software development, and the relationship that binds the three. The resulting paradigm shift could lower the cost of software and produce prosperity similar to the one induced by ultra-cheap oil in the 50’s.
Perspective: In addition to being a ‘think-piece,’ the presentation offers pragmatic recommendations for the Agile champion in three critical areas:
- It explains how the Agile champion can cross three chasms that tend to form in the course of large scale Agile rollouts.
- It explores how to apply Agile priciples to software deployment and operations.
- It shows how earned value management can utilize ‘real time’ customer feedback in companies that embrace end-to-end Agility.
With the successful release of Enterprise Profile Management 1.0, I asked Nick Beaugeard – Founder and Managing Director of HubOne - to capture and share with us his Agile development experience. Some of the threads he describes might have been mentioned in other posts in this blog. Others, like “Invest in your method and tools before you hire people, not after you hire people!”, appear for the first time. Whether mentioned here before or not, the ‘secret sauce’ is Nick’s ability to pull so many threads together. The power of so doing is nicely expressed in Nick’s guest post below.
Nick’s been involved in Tech for 27 years (if you include the games he wrote for the Apple II aged 9) and has been involved with companies like Microsoft, CSC, JP Morgan and many others. He’s also ran a number of start-ups, from web 2.0 to services to solutions companies and has been successful with a number of those. Nick has a passion for all things Agile, but prefers to design the methodology to suit the purpose, rather than rely on a one size fits all method. Notwithstanding this, Nick has some notoriety within Dimension Data for passionately changing solution development from failing waterfall to a test based development approach, suiting solutions and services.
Nick lives on Sydney’s northern beaches with his wife, four kids, two mice and a framed copy of the fabled W.W. Royce “waterfall” speech to the IEEE.
Here is Nick:
I’ve ran start-ups before. I’ve even managed the development of products before, but this is the first time I’ve set up a start-up with the sole goal of developing a product and bringing it to market. Thinking back on the last 8 months, I’m not sure I’d have taken the challenge on in retrospect, but we did, and we succeeded and so in this post, I’d like to share with you how a micro-startup with a budget of $50,000 can design, develop, release and certify an Enterprise quality product without going both broke or mad….
During my career, which spans everything from support, through solutions and has a great deal of focus on Systems Management, I’ve been constantly frustrated by something which should be really simple, how to find people with specific skills or responsibility. Seeing that the problem still existed, I set out to build a solution which would attempt to solve such a problem.
The first step on the road was to meet with potential customers. At this stage, I had barely a germ of an idea. It could be written in 20pt type on a single piece of paper. Nevertheless, I met with over 20 different potential customers and attempted to pitch the “solution” to them. The feedback I got was extensive, but the main and core piece of information was that the solution had value and merit and if we could deliver then these customers might just buy the software. I even went as far as to ask them how much they’d pay for such a solution and got a fairly consistent figure of about $20 per year per user.
I realised at once that the problem I was trying to solve was not a database problem. In fact it was a directory problem so I set about investigating whether I could produce a solution using an LDAP directory.
Right at the beginning, though, I made an investment in tools. I implemented great source control, issue management, task management and a build platform, just like I was in a huge team.
I also made sure I adhered to issue and task management and made sure that I was forced to complete the criteria for each check-in. I know that sounds stupid, and it must have seemed so… The CEO of a start-up assigning himself issues only to resolve them on check-in. However I believed it to be easier to implement the processes I wanted before I had a team on board, demonstrate me using them and it would be WAY easier to get the team to use them!
To test if my architectural hypotheses was correct, I wrote a very, very basic API. This small piece of code was able to perform some CRUD (Create, Retrieve, Update and Delete) operations on my own custom directory objects.
Let’s read the above again… See I had no spec, some interesting comments from customers and just went ahead and wrote a prototype API. Next I wrote some Unit tests which exercised the API and went back to my customers to see if I was on the right track.
That bit was tough. It takes a fair amount of imagination to see a simple set of unit tests and then extrapolate that to a completed product. However my friendly customer s were very patient as I explained that a response of “Passed” actually meant what I just explained had happened.
Once again that feedback helped and I felt confident enough to prototype most of the API and almost completely complete the schema. Once again I created a bunch of unit tests, but this time I focussed on the core scenarios as discussed with our customers.
Still at this stage, we had spent almost nothing, had a good, working and testable prototype API and a schema which worked.
It was then time to go and get a couple of developers. I knew a couple of my close colleagues had just resigned from another company so I asked them if they’d come and work for me, at a vastly reduced rate, for some stock in my new start-up.
Just the stage for a spec, huh? We’ve now got more than one developer so obviously need to write down then entire goal of the solution…
I thought not. My API was just a prototype and needed to be secured, consolidated, better documented, globalized and tested for performance and the unit tests demonstrated exactly how things should work. My new, fresh team set to work on tidying up and completing the API, working on issues and tasks and performing check ins. They also got told whenever they broke a build.
We were then seriously thinking about building a web services layer. This had several advantages, not the least being that we could support clients on multiple platforms. However, I was still a little uncomfortable with my API hypotheses and really wanted to build a client that exercised the entire API before we invested in SOAP and web services.
Therefore we set the challenge and therefore the scope of version 1. Version 1.0 would deliver a server (LDAP with an Installer) and a client (Windows XP and above) which talked to the LDAP server using our API.
That made the next challenge was the UI. This is a problem for me as I’m not one for having any design skills at all. However I could have sat down and tediously wire framed every screen and interaction I and my customers wanted.
However I knew a better wireframing tool – the IDE we used to write code instead. I sat down and started to craft a UI, using a lot of trial and error. In 7 days, I had a UI which exercised the main aspects of the API and the code base…
And that’s how our development stayed, I’d prototype (wireframe with code) a feature and the devs would then go and finish it.
We found bugs in the API, sure, but never needed to write new API methods to make the client work.
In the final weeks, we just worked on testing and fixing bugs… The test plan you ask? – Well that was the user guide! A full test pass meant running through each page in the user guide and doing everything it said.
A recent code review showed there was none of my prototype code left in the platform, but it didn’t matter. We shipped the product and spent less than the $50,000.
In conclusion our method was:
· Speak to your customers. Not lots, all the time!
· Invest in your method and tools before you hire people, not after you hire people!
· Make the software function, before you spend time making a UI function.
· Continuously test, fix and test again and don’t be afraid to throw prototypes away.
Last Friday we released version 1.0, go download it, you be the judge of how we did!
- The dissatisfactory state of affairs in enterprise software as characterized by Crawford and Mathews in their description of Consumer Underworld relationship between vendor and customer:
Ignore my needs… Be inconsistent, unclear, or misleading in your pricing… Offer me poor quality merchandise and services that I can’t use… Give me a reason to tell my friends and relatives to stay away…
- The potential of Open Source Software to become a disruptive technology in the sense articulated by Christensen:
Open Source Software is becoming ”good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, Open Source Software will steadily gain ground from traditional enterprise software vendors
… only 10% of Americans now saying they trust large corporations, according to the Apr. 8 edition of the Financial Trust Index. Some 77% of Americans say they refuse to buy products or services from a company they distrust, according to the 2009 Edelman Trust Barometer. [Highlights by IG].
The statistics given by Zuboff link the two observations cited above. One might argue that Crawford, Mathews and Zuboff deal primarily with consumer behavior, not with procurement of enterprise software. True that this argument might be, I sincerely doubt that the two worlds can be kept apart. At least some of the folks who license and use enterprise software must be represented in the data given by Zuboff and are likely to act accordingly in their corporate roles. Moreover, her statistics seem to be quite consistent with the recent warning to high-tech issued by Christensen:
If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.
No, this post is not about today’s GM bankruptcy filing. Rather, it is about coming to terms with a phenomenon similar to rust – software decay.
An IT application development team I met with recently indicated they reached the point of allocating 80% of their resources to software maintenance. Various colleagues of mine report similarly worrisome figures experienced in their practices. As a matter of fact, some of my colleagues consider such figures endemic.
It might indeed be hard to visualize a rusted line of code. Decay, however, applies. To quote Capers Jones:
All known compound objects decay and become more complex with the passage of time unless effort is exerted to keep them repaired and updated. Software is no exception… Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.
Hazardous that software decay is operationally and economically, it is lethal once it becomes embedded as a revenue generator in the business design for enterprise software. In particular, high maintenance costs as part of planned obsolescence invariably lead to the sorry state of affairs characterized as “Consumer Underworld” in The Myth of Excellence.
If you find this post a bit dramatic, please read Christensen’s recent post on the titanic efforts to turn things around launched by GM when it was already too late. Christensen concludes his post with a very pointed warning:
If you’re curious to know what lies in store for Seattle and Silicon Valley, spend a day walking around Detroit with the Ghost of Christmas Future.
Securities analysts believe that companies make money. Companies make shoes!
Readers of this blog might have said “software” instead of “shoes.” The point would have been similar to Drucker’s. Good financial management is no doubt important for your company’s success. It is no substitute, however, to focusing on the business you are in, the technology(ies) that drives the business and the effectiveness of the underlying systems and processes.
The current macro-economic situation gives you an opportunity to soberly assess the viability of your business design (as distinct from doing a lot of financial engineering). With asset inflation corrected, measuring the effectiveness of your business model in terms of the ratio Market Value/Revenues is much more meaningful now then it used to be prior to September 2008. As pointed out by Slywotzky in Value Migration, a market value to revenues ratio lower than 0.8 indicates value outflow for your company and possibly for your industry.
For software companies, the impact of “good enough” Open Source Software should be assessed in conjunction with close examination of the market value to revenues ratio. Twitting from the recent OSBC conference in San Francisco, colleague Andrew Dailey of MGI Research reported “… ERP/CRM are viewed as least susceptible to open source disruption… due to high transaction volumes and high integration needs.” Conversely, Andrew considers office productivity software as ripe [for the picking by Open Source Software]. I am personally of the opinion numerous Application Life-cycle Management tools could be massacred by Open Source Software.
The confluence of the threads highlighted above poses a fairly unique opportunity for the Agilist to convey a major premise of Agile to his/her executives. Like a thriving Open Source Software community, a hyper-productive Agile team can pick a ripe market faster and cheaper than an old fashioned software company could. Moreover, if a company is in one of the markets that are susceptible to an Open Source Software onslaught, Agile can (up to a point) provide defense against such onslaught. Whether you choose to attack or defend, Agile software gives you the advantages of proprietary software at a fraction of the traditional cost.
In her recent post on the Rally event in Los Angeles, Jean characterized the energy in the room as “electric!” Yesterday’s event in New York was characterized by similar energy. There was something in the air – folks having a great time learning about and discussing the subtle points of the art of making great software.
Governance was a major topic for the participants in NYC. Those representing financial institutes highlighted the inevitable delay and disruption to the process that change control boards cause. Media folks indicated how difficult it is to reconcile the editorial process with the technical process. A disconnect seems to be happening in both cases: Agile is not broadly accepted beyond certain scale, nor by all corporate functions. Hence, various attempts to “harness” Agile, to only use it selectively.
Governance seems to be applied more pedantically these days due to cost cutting measures. In particular, experimentation is frowned at in many place. The simple fact that Agile fosters innovation through affordable experimentation is not fully understood. Nor are the precious life-cycle effects of innovation adequately comprehended.
I came out of the NYC event convinced that we as a movement have a great opportunity on our hands. What we -Agilists – do works quite well. The need clearly exists to elevate Agile to the enterprise level. We will be solving a real problem in so doing.