I have recently been involved in the modification of several software systems. In one system, service provider preferences changed, which required code that interfaced with the new provider to be implemented. The presence of engineered software architecture simplifies change. A desirable architecture for a system with uncontrollable external dependencies facilitates changes that are localized to specific parts of the system.
One company wanted to use a hosted Microsoft Exchange Server solution, but their proprietary system depended on an in-house mail server. In this case, the system depended on a single mail component, and implementation of a component that worked with the hosted solutions provider and exposed the same interface to the proprietary system was all that was needed to make the transition. Code that had a direct dependency on the mail component required minor modification of references to the old component. All other code in the system was unaffected.
There are situations when elegantly engineered software architectures cannot be devised and deployed. A client demanding that a system be delivered earlier than completion estimates provided by engineers is such a situation. If a business deal depends on meeting client deadlines, then an engineer may opt to evolve a prototype into the production system. After meeting the deadline, the engineer may want to refactor the system into an architecture that is well thought out. This allows the engineer to make future system changes easily. Refactoring is an incremental approach toward elegant software design.
An excellent software engineer can change the core system into a more elegant architecture without changing the end-user experience. Being able to repeatedly perform this exercise easily indicates modularization of the user interface and the core system. The core system can be developed without affecting the end-user interface, and it can be deployed for many users without affecting their respective user interfaces. The benefits of modularization can be extended to software dependents. Excellent software architecture permits changes to software components without requiring massive changes to the overall system. Excellent software architecture makes effective use of software component modularization. Ease of change is a good reason to invest time in developing software architecture before implementation of the production system.
UCI’s School of Informaiton & Computer Science made Slashdot today for their research in topic modeling. Organizing a large number of texts in such a way that mining the collection for useful information can be done effeciently is a challenging task. Managing Gigabytes: Compressing and Indexing Documents and Images has been on my Amazon Wish List for some time. I’m fairly certain that it will make an interesting read for those days at the park, beach, or coffee shop.
Thanks to Mike Marquez for pointing out to me that SysAdmin Day is tomorrow, July 28. Happy SysAdmin Day to Eric of MSA, Andrew of ISM, Jay of Opt3, the people at our co-lo, and to everyone else that is “In the Trenches (IT).” When the shit hits the fan, technically speaking, we appreciate the peace of mind that comes with knowing that you have it covered.
A data center in Downtown Los Angeles may boast about the multiple backup power generators they possess, but is it enough to deal with power problems that span the whole city for multiple days? Although problem scenarios may seem farfetched when an information architecture is functioning normally, problems do occur as exemplified by the extended power outage around New York City. Consolidated Edison, a 10 billion dollar company, was unable to provide highly available service. A majority of co-locations do not spend as much as ConEd to create an environment that supports high availability, and a majority of companies are not willing spend too much on minimizing downtime.
To minimize the cost while maximizing service availability, a solution for providing high availability should include at least two data centers that are in separate geographic regions. This is more advisable than building up a single super data center. As an example at a smaller scale, buying two servers and configuring them for high availability is cheaper and safer than buying a single server that is supposedly fault tolerant. A single server, by definition, cannot provide redundancy that is needed to foster high availability. When dealing with high availability, scaling out is simply better than scaling up.
Time has been scarce these past few weeks, and this week in particular has been the busiest. Recovery time from work has been compressed to approximately three hours a day. Each work day this week has started at approximately 6:30am. At that time, a 1.5-hour commute to Irvine begins. Then, approximately seven to nine hours of continous work is committed. Work is interrupted by a 1.5-hour dinner, and work resumes for about three hours before the one-hour commute back home. Another two to three hour session of work occurs before I sleep and recondition for the next day. Time for sleep has started between the hours of 11pm and 2am this week. This week has been very busy. More importantly, this week resulted in multiple accomplishments.
I was dropped into a somewhat alien environment and utilized as a resource to develop the environment into one of stability and normalcy. I believe I effectively used the resources that were made available to me, and these resources were vital to the timely completion of my objectives. I observed a lot of interesting things that I intend to examine in future postmortems.