Number of applications within C&W. Currently, still, at around the 1,500 mark apparently. This is causing us as a company to try and reduce this number (a good idea really - 1,500 is far too many). But it got me thinking as to how its going to affect my role.
Our team traditionally wrote small, quick ASP 3.0 applications to solve a particular business problem. Because they were specific, they were usually very good at what they did, and some got used very widely. The problem is that with this drive to reduce systems, we're moving now into supporting and developing "enterprise-wide" solutions such as SAP, Siebel and various content management systems. And if we're not doing this right now, its definitely the way we're heading. No biggie, you might think, but I've been thinking about this, and I don't think using these sorts of systems actually provides the business with solutions to their problems.
The problem with SAP or Siebel or whatever is that they're square pegs trying to be forced into round holes. A system which is generic enough to do "anything" is never going to match what the business users require, because their specifics cannot be accounted for. The great thing with our previous approach was that the business got exactly what they wanted to deal with the problem. And it was lightweight, web-based scripting, so if half-way through they realised it needed to work in another way, or another thing needed to be added, then we could easily adapt to what they wanted. We tended to follow a rough Extreme Programming methodology, and I thought it worked quite well. Certainly, my two most successful applications were written in this manner. Each solve one specific problem within the business. Job done.
But with these new "enterprise systems", we can't solve their problems - we start instead adapting their problems to fit in with our system. Now, I'm not sure exactly what our role should be within the business, but it strikes me that it should be to solve business users' problems. To make their jobs easier, quicker and more effective, thereby saving and making the company money. Whilst I accept that support for all these applications is difficult, its surely no more difficult than supporting several bastardised SAP modules, which don't accurately solve the business problem.
So going forward, what should be our plan? I'm not sure I know, but I can't approve of trying to force everything through systems that won't properly fix the problem. However, I'm also aware that having thousands of tiny bespoke systems isn't great either. Particularly in ASP 3.0, a soon-to-be-dead programming language. Maybe the answer lies down a middle path, something like a well-designed object-oriented system (Java or C# I guess). My thinking is that a well designed system would allow us to firstly meet and solve the exact problem the business has (we're writing it after all, so it should at least do that). Secondly, we could then build on this, and increase the scope and scalability of the application to try and include other similar problems that we come across. For example, a lot of the applications I used to build were basically fault tracking systems. They all had specifics that would prevent them fitting nicely with Siebel or anything like that, but they all had key modules that would have been the same. A well designed, carefully managed object-oriented application should have been able to scale upwards to include new functionality, written by any one of us. Perhaps I'm a little naive in my thinking, and its not possible in practice to do this, but this is currently my best idea. Any thoughts?
