אגב, בזמנו, שנת 2005 פרסמתי מאמר ב- CUTTER תחת כותרת זו:
http://www.cutter.com/content/architecture/fulltext/advisor/2005/ea050914.html
INFRASTRUCTURE: THE FORGOTTEN ASPECT OF SOA
by Pini Cohen
Service-oriented architecture (SOA) has become one of the top priorities of IT organizations and application providers. By applying SOA, IT organizations intend to reuse technology, processes, and people. However, as SOA becomes prevailing software engineering practice, not enough has been done to adopt SOA concepts into the infrastructure domain.
Within the infrastructure domain, we too often see an endless variety of components. For example, there may be an enterprise resource planning (ERP) application server (with specific memory, CPU, and input/output characteristics), a specific server for the business intelligence (BI) viewer, and so on. This is also true for the processes that are related to these infrastructure components. For example, users too often have one backup policy for customer relationship management and a different backup policy for their Web application environment, as well as a specific way for dealing with the database administrator requirements of different systems.
We believe that as IT organizations apply SOA principles in the business and applications domain, they should also apply SOA concepts in the infrastructure domain. Organizations should define services in each of the infrastructure domains (storage/backup, compute/server, DBMS, etc.) and reuse these services as much as they can. For example, in the compute/server domain, infrastructure organizations should define services such as "entry- level server," "clustered medium server," and "high-end server," and so on.
The defined service should also include both the "power" of the server (basically related to the number of CPUs) as well as the supported operating systems, software, and related processes such as installing, replacing the server when it is down, and updating patches. In other words, it should include complete SLA related to compute/server needs. That way, when a new application is introduced, only the defined compute/server services will be used to build the new application infrastructure.
As in the application/business services domain, applying the SOA principles in the infrastructure domain will enable the reuse of technology, processes, and people.
Users may argue that these principles may cause waste in some degree, since projects will sometimes get (and pay) for better SLA than they require. For example, if an application requires mid-range storage with disaster recovery planning (DRP) but DRP exists only in the high-end storage option, then this project should utilize the more expensive high-end storage with DRP. In the long term, sticking with the defined services will be cost- effective to the organization, since adding new service requires not only different technology but also different processes and skills.
Bottom line: users should apply SOA principles to the infrastructure domain today to get lower total cost of ownership and better agility in the long run.
גם ההמלצה השלישית שלי מתייחסת להפשטה של תהליכים.
לסיכום, בייחוד בזמן זה כדאי לבחון בנייה של שירותי תשתיות.
אין תגובות:
הוסף רשומת תגובה