Many enterprise network workers are now adopting automation technology as a means of completing operational tasks, and of creating a more efficient environment within an IT enterprise. One of the advantages of adopting IT automation is that it helps to deliver optimal IT management, without the need for any significant capital investment.
Once a system is automated, the software should be tested holistically to ensure the business' objectives are met. Unit tests should be self-contained, so that the system is not affected by external changes. Unit tests are conducted in isolation to avoid a domino effect of failures stemming from one failure. Tests should be conducted as a run-on with a single command line or a graphical tool.
The advantage of test automation and automated functional testing is that they will contribute to an overall reduction in the costs associated with testing, and they help to improve the quality of the software. Configuration testing is important in that it allows for the easy identification of faults and dysfunctions within an enterprise that has migrated to cloud computing.
Cloud Computing and Organizational Challenges
When a business migrates to cloud computing, organizational challenges will arise. The main focus will be upon technological components such as automation, security, policy management, and organizational behavior. As operational software and hardware models are implemented in the business' data center, they trigger a challenge for the employees throughout the architectural setup of the business to become acquainted with the new technological changes. The challenge then will be to ensure that these organizational changes are properly managed, so that cloud computing can be successfully deployed. Configuration testing should be carried out on an ongoing and automatic basis, so that factors which contribute to inefficiencies can be readily identified and corrected.
As the economic limitations continue to affect all aspects of businesses, IT enterprises are forced to better manage their existing systems, which can amount to as much as 70% of departmental costs. A major part of managing the IT departmental functions to achieve efficiency lies within the department's ability to create a smooth interaction between development and operations. This is where DevOps comes into play.
DevOps Bridges the Gap Between IT Developers and IT Operators
DevOps is basically a professional or a functionality (set of principles) that is designed to handle any disconnect between developmental activities and operational activities. Manifestations of this disconnect are deemed as inefficiencies within the IT department. The need for integration between these two arms of the IT department is key to the sustained success of an organization that has been, or is going through, the process of automation.
There is generally a disconnect between personnel within the developmental arm of the business and those within its operational arm. This disconnect results from a difference in how each arm views their role within the business. Develop-centric individuals are of the mindset that it is their duty to effect changes, as they are paid to respond to changes in the business, and are charged with developing and implementing operational software in response to these changes. Individuals within the operational arm of the department are generally resentful of these developmental changes, as they tend to disrupt their function of keeping things going, and keeping the business' revenue flowing. They resent the feeling of instability and unreliability that these changes cause within their operational umbrella. This can only contribute to isolation in thoughts and functions, which are feeders for inefficiencies.
A DevOps professional is charged with the responsibility of bridging the gap created by these differences, and ensuring that the project is a success. The role of the DevOps professional is similar to that of the Chief Engineer. They must oversee or facilitate the integration process to ensure product delivery targets are met, and that other aspects of the product development process such as quality testing, feature testing, as well as maintenance releases, are carried out.
DevOps essentially ensure that these are done so as to improve reliability, security, and the faster development and deployment of productivity cycles. When a DevOps has to oversee several deployments per day, it is referred to as continuous deployment, or continuous delivery. DevOps are expected to have the necessary capabilities to foster or facilitate a more collaborative and productive relationship between the development and operations arms of the IT department.
The DevOps should recognize that the difficulty lies within the isolated mindset of both groups who should really be working in collaboration in order to achieve overall business success. A major difficulty faced by these businesses is that both arms are often geographically separated. Another factor lies in the continued use of the Legacy system by some enterprises. The relationship between each arm of the business, IT, accounting, finance, customer care, etc., will need to become more fluid, as the on-demand and flexible nature of the new IT environment demands this change in behavior. Each department will have to learn to flex, and respond to the need for immediate action on their part to fulfill the demands of another department, which in turn effects good product development. Allocation of time to the procurement department to prepare its annual report may need to be shortened, in response to a demand from the accounting or finance department for a budget report on the IT department. This creates the need for Enterprise Continuum.
Enterprise Continuum addresses the architectural setup of a business to achieve continuity in its overall functions and departments, both internally and externally, and irrespective of geographical location. This function allows for methods of classifying architectural and solution-based factors and drivers that will bridge the gap of communication and understanding within individual enterprises, as well as between vendor organizations and customer enterprises. The enterprise continuum is context specific, and provides that consistent language that enables engineering efficiency and the advantageous use of the functionality of Commercial Off-The-Shelf (COTS) products.
The Architecture Continuum offers a steady method of defining and understanding the genetic rules, relationships, and representations within an information system, while the Solutions Continuum offers a consistent manner in which the implementation of the Architecture Continuum can be explained and understood. The solutions reflect the agreements between customers and business partners that have been used to implement the rules and relationships within the architecture space. The enterprise continuum is comprised of both functions.
This level of continuum is important in the product development, automation, and configuration testing process. Once Enterprise Continuum is implemented, people within each aspect of the business in their various locations and functions could be discussing business architecture without even understanding where in the continuum they fall, but would still be referring to different points of the continuum.
The Enterprise Continuum allows for the re-usable architectural artifacts and solution assets that can be found within the enterprise itself, and the IT sector at large, to be organized and re-used in a manner that is beneficial to their investment opportunities. Aspects of this external architecture and solution artifacts within the enterprise continuum, that are part of the industry reference models and architecture pattern include those that are highly generic such as TOGAF's Technical Reference Model (TRM).
Moving Away From the Legacy System
Once all the players understand the need for organizational changes, then resistance will lessen. If the Legacy System is still used by the financial department, then the necessary resources must be made available to effect the required changes, so that the department can become fully functional and able to respond to demands from other departments. They must also be equipped to adequately handle the day-to-day operation now required in a faster paced, more technological environment.
The Legacy System is an old and obsolete application program that can no longer adequately and efficiently serve the needs of modern enterprises. As a business strives to implement cloud migration by moving away from this old application, it will better enable it to benefit from the all aspects of cloud computing and automation. Alternately, some businesses may opt to maintain or re-engineer their Legacy System as opposed to scrapping or replacing it. Keeping the Legacy System might be cheaper than upgrading or migrating to the most recent technological software program, but will this be the case over the long term? How will it affect the function of the other departments, and what of the time factor involved in producing information with the outdated Legacy System? Can it fit into the on-demand or SaaS nature of the other aspects of the business?
Optimization is the key to maintaining a successful and sustainable business. Reducing cost is a significant factor in realizing business optimization. By moving away from the old outdated systems, and taking advantage of the umbrella-type operation of the new cloud computing and automation systems, businesses will be opting for a cheaper (in the long term), faster SaaS system that is accessible 24/7.
What happens when the procurement department still uses the Legacy System, which would obviously use a different software, and different tools than those used by the accounting or finance department of an enterprise? How well would both departments sync in the information they supply and demand of each other?
Disadvantages of the Legacy System in an Automated Enterprise
There are several disadvantages a business would face if they opted to retain the Legacy System.
* The mainframe hardware for which Legacy Systems were written is no longer available, so the system would be expensive to maintain.
* The mainframe hardware of the Legacy System may not be compatible with the organizational purchasing policies of the current IT department.
* The range of support software on which the Legacy System operates may be obsolete, and is no longer supported by the original providers.
* The immense application data that is processed by the Legacy System would have been gathered over the lifetime of the system. Inconsistencies and duplication of the data in various files may cause it to be inaccurate and unreliable.
* It may become too expensive to maintain and too complex to allow for adaptation to the constantly changing IT applications, and changing business environment.
Dealing with Configuration Drift
When the enterprise's production and disaster recovery infrastructures become out of sync, a configuration drift has occurred. These are pretty common occurrences in today's IT world, and elimination, though a crucial process, is a difficult one. Eliminating a configuration drift is essential to the recovery process.
The configuration testing software should be able to carry out functions such as:
* Identify hidden vulnerabilities within the hardware.
* Ensure business continuity by automatically detecting and fixing potential problems before they impact business operations.
* Minimize the number of failures due to host configuration errors by addressing uncovered issues before running full DR test or HA failover. This will ease the failover testing pain, improve the enterprise's DR and HA testing results, and limit the amount of time the IT department spends on testing and DR readiness.
Overall software configuration management is best supported by infrastructure unit testing. DevOps are instrumental in overseeing the smooth integration of product development and testing so that a business gains maximum benefit from its investments