Before discussing the best approach, it is worth noting that the CIO must be willing to dedicate a lot of time and resources. Existing development and maintenance doesn’t have to stop, but it may slow down depending on available staff. It is a very large endeavor, and requires big planning, patience and persistence to see things through. It is critical that the CIO completely understands this and is onboard. If not, the process will for sure fail.
1) Hire (or identify) a qualified Enterprise Architect who is capable of doing enterprise domain analysis. Depending on the size of the organization, this process may take anywhere from a month to over a year. This is the most important step toward improving things and cannot be sacrificed.
2) Once domain analysis is completed, begin translating the domains to real world entities. For example, if someone calls a person a “client” in one department, and a “customer” in another, investigate to see what the differences are and see what is in common. You may discover they are exactly the same thing, or you may discover a “person” domain entity would have almost all the required information and a “client” inherits from that and has an additional attribute called “client relationship” or something of that nature. Organizations often come up with their own terminology too. Don’t make your real world domains out of those. Instead, translate the organization’s terms to real world (based on a definition from a dictionary). The reason this is important is because a real world entity represents reality. If you begin creating entities based on an organization, they may be flawed because of lack of understanding by an end user, or simply because someone new gets hired that doesn’t want it to be that anymore. If you create real world domain entities that you translate organization entities to, your domains will be safe. Example: Someone calls something a “schedule”. It isn’t a schedule by the definition in a dictionary. It’s a client calendar day tied to a specific process in their eyes. You can always make a user interface say “schedule” but don’t fall victim of the domain entities actually being the flawed representation. Call it “personnel client schedule” or something like that instead, and again, map it to real world (may be a combination of 5 or more real world entities at that point).
3) After step 2, you may identify some flawed processes in the organization. If possible (and within reason), change the flawed processes. No good reason to develop around bad processes. Sometimes this isn’t possible due to authorization, politics, etc.
4) Begin to design databases with the domains separated for each. For example, most businesses deal with people, so have a “person” database that has common information about people: first name, last name, home address, home phone, etc. You may discover that some of the things you thought were simple domains, like “home address” may end up needing to be in its own “address” database. For instance, if you deal with land and property, you may need addresses that don’t belong to people (owned by a bank for example). This would be a reason to move addresses to its own database. As you can see, domain analysis is extremely complex and requires a good deal of time. But once things are separated out, you will see all the duplicate data you’ve been dealing with for so long.
5) Come up with a plan to begin translating existing systems to use the new databases. This process is highly dependent on the staff, system capabilities, architectures, etc. Web services and Service Oriented Architecture can greatly aid and simplify this process because of the loose coupling concepts. You may needs to have multiple systems up at the same time during transition. For example, you may have an old Mainframe application for dealing with employee information. You may have to create a new Java or .NET system that pulls this information in a batch process to a more available SQL Server or Oracle database (technologies are just listed as examples). You may also discover some of the data from the existing systems will no longer be needed once the new ones are in place. It could be there were duplicate feeds for a given process (or separate processes). All of these factors will help determine the timeline for shutting off existing/older systems.
6) Now that you’ve figured out what new systems you need and are very familiar with the domain entities, take a look at developing a solid framework. A framework should consist of not only persistence layers, but also user interface layers, logic layers, etc. You can use other 3rd party frameworks as part of yours, but make sure you do have your own as well. It might end up just being wrappers around the others, but it will ensure you can solidify and protect your new systems since it will be under your control. Also, ensure the enterprise architect is familiar with various technologies and understands the lifecycle and risk associated. Stick with technologies that are sound and have a long future ahead to minimize re-writing in the future. Don’t be “bleeding edge” and incorporate something just because it’s cool or a new buzzword. Figure out first if it will be around for the long haul and determine its popularity. Don’t invest in technologies that your staff can’t support/understand or ones that will be impossible to find other hires to manage.
7) Begin development of the new framework.
8) Simultaneously with the previous step, begin architecting the new systems (back end and front end) based on the framework.
9) After the framework is solid and tested, begin implementation. The planning and architecture of the framework is actually the most difficult part, if done correctly. The implementation of systems may take some time, but it should all go smoothly if the plan and framework were constructed well. It can’t all be done at once, so implementation will have many phases. Start with something small first to familiarize yourself with the transition process. Once you have a couple successful transitions in place, tackle the larger domains/systems. New development of web services can begin to supply this information to new systems in development. As the Mainframe system is phased out, all other systems have started relying on the new web service (which gets its data from the original source, the Mainframe). Once a new system is in place to input data into the SQL Server/Oracle database, and staff trained on a new system, the Mainframe system can be shut off. It’s also important to mention that there are 2 pieces to this puzzle. Firstly, the data. Secondly, the user interface/interactions with the data. If going the web services route, you can actually have all the data handled before evening beginning the design of a user interface.
Now, during this whole process, it is very important to be mentoring and training the staff. Make them feel involved and get them excited about the changes coming up. Many people don’t like change, mainly because they are scared of it. Help them to feel important and needed in the process and most will gladly give it their all. It’s also important to help ones not feel insecure about the systems “they” maintain. Make sure they understand the goal isn’t to eliminate their job, but to help them get away from maintenance and get excited about doing new and better things.
Now that the framework has been developed, and all existing systems phased out or transitioned to the new framework, you have an extremely robust, reliable, consistent, and maintainable set of systems (if architected well of course). Congratulations, the efficiency of the IT department will be through the roof and continue to improve day by day.
No comments:
Post a Comment