Introduction
Why with all of today’s technology are so many development shops still creating projects in an antiquated fashion? It’s not the simple question of thin or thick client, client/ server, browser based. It’s not even the question about development language, C#, VB, Java, PHP, Python, Ruby or even COBOL. Forget about the extensions and libraries, all the different languages have them and sure some are well designed, of course don’t reinvent the wheel. You have your design patterns, SOA, and different methodologies agile, waterfall and even wow extreme programming. Hold on, I’ll go scour and grab all the buzz words and give the big sell. Oh forget that mess, you get my meaning.
Where is the architecture? Oh forget all that other mess, sure you can modularize, minimize dependencies, utilize design patterns up the wazzoo and get wonderful but where is your maintainability, expandability. How do you go about fixing a defect? Who is responsible for the fix? The person who developed the module or can it be anyone? Now you have version control issues, and your QA issues, source merging issues, is there rollback plan? What about the legacy vs. new data after adding a new feature? At the end of it all, what’s the maintenance staff? Well you have the picture, and even better the dream of developers out there. They have their job security.
This is a crazy discussion; yes every IT shop has varying requirements. Yet, many IT shops have the same nightmare. They all have various needs and business requirements for their systems operations. Yet, how do they expand as requirements change? This is not a discussion about the some system specific applications, such as operating systems, word processors, the spreadsheets, some hardware embedded solution or purely utility based. Those are specific requirements out of this scope, and to be discussed in an upcoming episode. In my belief, most application are business database type application dealing with customer support or financial based.
How does an IT shop proceed? There could be a change in process and focus. There are solutions for all the unique and various requirements. And there would be many architects and experts that would provide various solutions for the varying requirements. They are not wrong! I just believe they are not thinking about the big picture, this is where focus is lost, “The Big Picture”.
The most perfect example and opportunity is a brand new IT shop all starting from scratch. Where do we go from here? And there are many options. I think most will purchase a system which will meet most of the needs. They may get lucky and be in a business where there is a package that completely meets their requirements. The plan is set. Now look into the future as they grow and expand, and may even change business plan and move in various directions. Now, they say let's develop our own application and so we have the ability to customize as needed to our new requirements. Then several years later, what occurs as direction changes again?
Some shops are in this situation having a new legacy system that needs to be upgraded. What occurs now? Technology has changed and maybe written in an outdated language. Do they continually upgrade the legacy system or perform yet another rewrite on a new system patching in the old? New you have new technologies, new patterns, and new libraries. What happens now? Are they using the same experts or new experts? There are a few frames of thought in this circumstance. You can just maintain the existing code base, perhaps rewrite modules as needed and continually build on and place duck tape along the way. There are many considerations; planning, budget and even talent. Many existing is working exactly for what it was intended. Does the system meet the business requirements? Will there be expandability as the business change? And given if the IT shop went the route of purchasing an off the shelf solution, has it been able to grow as the business as grown?
Where does this madness end? It is the big picture and it is in your architecture. Through my experiences and many various opportunities and have seen all sides of the inner working of an organization, the good, bad and the ugly. Yet, one prevailing thought in many organizations is the barely manageable legacy systems. Definitely not all of them were terrible, it was the architecture. I say this now just because of experience and reflection on past projects. I have to admit some of my projects were terrible and non-maintainable and even a mess, but today and going forward, I want to have a new outlook.
My challenge to all you architects, developers including project managers is to create nice systems. Give forethought to what is being created and really ask yourself “How the team can make it better?” Can you make a better system which is the holy grail of being maintainable, expandable and yes satisfy your customer’s requirements? And now I hope all you are asking the question “How can we do that?”
My simple answer is to “Simplify”. I hope you all have heard of the “KISS” expression “Keep It Simple Stupid”. That philosophy has been rotating around for the longest time, yet nobody really follows through.
One of my recent projects required me to create hundreds of form letters to be email or faxed and incorporating various data elements from the system, needing to be recalled and resent as the original. The business requirements, minimal as they were, asked me to create individual screens for each letter. To be fair, each letter needed different information from various areas from the system. Perhaps, my management just wanted me to keep me busy for weeks on end, creating all these reports or letters, but I decided to keep it simple. So, I was lazy gave it some thought and generated these forms within 4 days. And not only created the hundred but created additional limitless numbers within minutes.
Allowing you to reflect and consider possible solutions, many could give lots of feedback. What was created was an engine with an interface. The engine was able to collect information about the form letter, fill in any additional information from the system, allow the user to fill in additional information as necessary, send the email or fax and saved the original as it was sent for historical purposes. Letters were stored in RTF format and a table was able to select the proper letter and version to be sent. An XML of all the fields as entered was also stored to be recalled at any time. Once this engine was created, the source code wasn’t touched again for years. It handled any additional form, and even the various versions, yet still was able to recall any old version.
What is this Engine? Well, allow me to digress. I am always looking at new technologies, and various ways to solve a problem. Years ago, being an avid gamer, I started noticing these huge games way pass the Pac Man or the Tetris era; I started looking at the Halo, GTA and various other games and researching the technology on how they were created. Yes, they all had graphics engines to help with the 3D applications, but I also concluded there must be some scripting to follow its particular story line. And discovered why not apply this to applications? And realized they can be applied to many real world situations.
Now back to the architecture, yes this requires a little more thought and I say generalize the problem down to the common functionality. It is not over designing the problem, and adding functionality is not necessary. It is about designing a solution that is elegant and will work in many applications. I would rather code a solution once, than be stuck into recoding a solution many times. In real world examples, almost all manufacturing and mechanical type of jobs are accomplished using a pattern or engine of some fashion. Why not apply this to software architecture and development?
