To schedule an appointment or find out more about the services we offer, please call +1 425-281-6548 or send us an email.
Or use our contact form.
Read all news and events.
Follow us on Facebook:
October 10, 2013 : This is my first post on the Kalya blog, and the first topic I chose is very dear to my heart, it is about software development in the Enterprise.
Throughout my career, I have been involved in both Enterprise software development (Quintus, Business Objects, TriZetto), or software development inside large Enterprises (Charles Schwab, Chemdex/Ventro, Expedia, Sephora) and to me this felt about the same, we were developing software, some of it packaged and tested to be used by customers, and some released to production and directly to end users to create direct value. The names were a bit different, requirements were built by product marketing or product management in one, and by the business or business analysts in the other, but it was pretty much the same thing, we were drafting requirements to build software and get it to do useful things. Most Enterprises did some testing and slowly improving those practices as quality became more important, and most software companies had well established testing practices, although, as with everything else, some had almost none. It felt like the same thing with similar challenges wherever you looked.
Of course there was the notion of using Enterprise software to accelerate the delivery of value inside of the Enterprise. I had built some of that Enterprise software, I tested it, even worked with consulting organizations to implement it, but implementing it in the Enterprise seemed somewhat different. My first contact with Enterprise software deployment in the Enterprise, was when we were deploying Siebel in he late 90s: it seemed unusually painful and slow. Later, we deployed Oracle ERP in many Enterprises, and it was quick and fairly painless, but those experiences were noted as unusual or even greeted with disbelief when we claimed to have implemented Oracle ERP in 6 months. The more I progressed in my career, the more I realized how much trouble my peers were having putting those solutions in place. You had to go through the buy versus build decision, and all it's variations around "Am I going to buy a package or custom develop this", Of course in IT "package" was good, and "custom" was bad. Despite that belief, package implementations were seldom out of the box, they always required more or less customization, and in all cases you had to develop integration with your existing environments. Further, once they had those systems in production, so much was still left to to make it work and adapt to the ever changing business environment. In other words, the more you tried to avoid software development, the more you realized you had to do it anyway.
Fast forwarding to the past years, it has become clearer that non software companies have to embrace software development to remain competitive. IBM describes this problem at length in their paper "the Software Edge" and I have two key observations to offer:
I have seen those waves unfurl across many industries. I have seen the changes needed in how enterprises operate, and I founded Kalya to help companies embrace software development, and the cultural shifts that go along, to become more competitive and ultimately more successful.