2 Dec 2012

EA Tools

Usually, an enterprise architecture project is a big project, where a lot of documents are created, managed and revised. For the purpose of helping consultants manage a huge amount of documents, software companies have provided EA tools. Nowadays, there are many tools are available, and enterprise architect can choose from various selections.*1

One of the most famous tools is IBM’s Rational System Architect. Systems Architect supports to develop various artifacts using EA frameworks.





However, this tool is not free unlike software developments tool such as eclipse. Rather, an enterprise architecture tool is pretty expensive shopping. In the case of Rational System Architect, the price of one user license is USD $4,190.00 (02/12/2012). This pricing have prevented enterprise architects from using these commercial tools.
"Traditionally, enterprise architecture tools are proprietary and have a reputation for being expensive to purchase, customize and run. In a 2009 report over 50% of respondents claimed not to be using a commercial EA Tool, with many making use of Visio, PowerPoint, Excel and/or SharePoint only and a 2008 survey indicated the cost of licensing as the main barrier for EA Tool adoption." *2
A problem of using Microsoft Office products for EA project is maintainability of the artifacts. EA program is iterative process and artifacts need to be updated. Thus, version control of artifacts is important, and it is difficult to do it on these Microsoft’s products.
"There are a number of underlying issues for organizations that use Visio, PowerPoint, Excel and/or SharePoint rather than an EA Tool; the information captured quickly becomes out of date, the ability to quickly and easily re-draw a different view of the information is not available, the meta-model must be manually enforced." *2
However, some open source enterprise architecture tools are available (and they are free!). There are two popular open source EA tools: "The Essential Project" *3 and iteraplan.
  • The Essential Project *3


  • Iteraplan*4

Usually, the cost of consultants are much expensive than the cost of tools. So, if it helps the efficiency of consultants in large amount, commercial tools will be worth the price. However, nowadays there are many alternative options including open source tools. Enterprise architects should choose these products depending on their purpose.

Finally, the followings are the requirements and comparison of EA tools, which are made by Gartner Group. These criteria might help to choose an appropriate tool.
  • Requirements of EA tools *2
    • A repository
    • A meta model that supports business, information and technology viewpoints as well as the solution architecture
    • Provides support within the repository for relationships among and between the objects in the above viewpoints and solution architecture
    • The ability to create or import models and artifacts
    • The ability to extract repository information to support various stakeholder needs.
  • Comparison of EA tools *5


References:
*1 http://www.enterprise-architecture.info/Images/EA%20Tools/Enterprise%20Architecture%20Tool%20Selection%20Guide%20v6.3.pdf
*2 http://en.wikipedia.org/wiki/Open-source_enterprise_architecture_tools
*3 http://www.enterprise-architecture.org/
*4 http://www.iteraplan.de/en
*5 http://www.mega.com/en/c/resource/p/analyst/a/resource-analyst0035

EA and BA

IT business is a quickly changing field. Many of new technology and business come and go, and so does new terminology. Enterprise Architecture or Enterprise Architect may be one of such words. In fact, the role of enterprise architecture sounds quite abstract.
“Enterprise architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution.” *1
This sounds similar characteristics as business analysis. Business analysis also aims at changing an organization to achieve business vision and strategy.
“Business analysis is a research discipline of identifying business needs and determining solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement, organizational change or strategic planning and policy development. The person who carries out this task is called a business analyst or BA.” *2
Well, does it sound similar as EA? What the difference between business analysis and enterprise architecture? Ronald Schmelzer summarizes the difference as follows:
“An EA’s role is to translate business requirements into capabilities that can be cost-effectively implemented, predictably managed, and reliably controlled. The central abstraction for the EA is the Service Model and other models that relate to information, process, system, and functional flow to enable the ongoing operation of the business. As abstract as this may seem, especially to developers, the BA acts at an even more abstract level.
BAs are primarily tasked with requirements generation and facilitation of communications with technical groups to make sure those requirements are reliably implemented. In this regards, while an EA has both feet firmly planted on both sides of the business-IT divide, the BA (even an IT BA) is weighted towards the business.*3
Now that we identify the difference between EA and BA, can we learn anything from BA field to make a progress in EA? One of ideas is integration and standardization of frameworks, knowledge, and best practices. Business analysis is also well organized area, and its practices in that field are compiled as BABOK (the Business Analysis Body of Knowledge).

This kind of standardization can reduce the cost of EA programs and make them more economical. We can this from the analogy in software industry, such as ERP software customization. Many of ERP software are sold as ‘package software’.  However, when a company buy and start using it, they realize that the software does not fit their business process. They, they start to customize the software, which sometimes become a high cost and high risk project.

Eric Kimberling summarized the risks of customization as follows:
“The reason for the controversy around customization is threefold,  First, it increases the complexity and risk of an implementation, while at the same time making it potentially more difficult to upgrade software in the future.  Second, it in some ways undermines the best practices built into the software, which software vendors often spend significant R&D developing.  Thirdly and finally, customization is often a symptom of bigger problems, including a solution’s mismatch with a company’s requirements or a lack of project controls during implementation.” *4
Customization of EA program might be inevitable. However, the notion in ERP software, which is proposed by Erik Kimberling, may also apply to EA program. A Packaged EA program may reduce the cost of EA program and provide more value of its user. Popular approaches such as TOGAF seem to be a good start. The more EA programs are executed, the more the framework will be refined. This is not an easy challenge, but more comprehensive and refined framework will promote more companies adopt EA program and will benefit them.


References:
*1 http://en.wikipedia.org/wiki/Enterprise_architecture
*2 http://en.wikipedia.org/wiki/Business_analysis
*3 http://www.zapthink.com/2008/08/13/the-business-analyst-vs-the-enterprise-architect/
*4 http://panorama-consulting.com/erp-software-customization-the-ultimate-sin-of-enterprise-software/

Value of Documentation - SLA

For providing IT services, a company usually develops a document called “Service Level Agreement (SLA)”. A SLA is a very detailed document which includes what is the responsibility of the company, what level of service the company provides, what is the disclaimer and so on. A company seems to spend a lot of time to develop such a document. Why does a company develop such a document?

SLA is one of the outcomes of IT service management activity of a company, and the development process is included in a part of ITIL. The current version of ITIL (v3) is composed of five volumes as follows: *1
  1. ITIL Service Strategy
  2. ITIL Service Design
  3. ITIL Service Transition
  4. ITIL Service Operation
  5. ITIL Continual Service Improvement
SLA is a deliverable of Service Level Management activity which is written in the ITIL Service Design volume, and it is one of the most important documents in the ITIL framework. Service Level Management (SLM) is one of five components in the ITIL Service Delivery area.
“It is arguably the most important set of processes within the ITIL framework. SLM processes provide a framework by which services are defined, service levels required to support business processes are agreed upon, Service Level Agreements (SLAs) and Operational Level Agreements (OLAs) are developed to satisfy the agreements, and costs of services are developed.” *2

 (Image Source: Lists & Notes*3)

Why is it so important? What is the value of service level management? There are many benefits can be acquired by developing service level management strategy. Harris Kern summarized three benefits gained by a good service level management as follows:*4
  • Harmony between the user and the IT organization
  • Efficiency of IT operations
  • Improved user satisfaction
Above all, Harris wrote that the most important aspect is that IT organization can grasp an accurate image of what their customers need. He also wrote “A Service Level Agreement (SLA) is a give-and-take relationship between IT and users; users articulate what they need, and IT gains support in getting the resources needed to provide it.”*4

The value of documentation is not only in the deliverable; rather the more value is in the process of developing the document.

References:
*1 http://en.wikipedia.org/wiki/IT_service_management
*2 http://www.teamquest.com/solutions/itil/service-delivery/service-level-management/
*3 http://www.listsandnotes.com/itil-v3-foundation-test-study-notes/
*4 http://www.techrepublic.com/article/measuring-for-service-level-management/5388735