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

27 Nov 2012

Value and Constranits of Documentation - ITIL

For IT project, documentation is significant. In fact, enterprise architecture framework is a framework for documentation. Many other practices for documentation have been developed. For example, the Information Technology Infrastructure Library (ITIL) is a common documentation practice for IT service management (ITSM). ITIL focuses on aligning services with the needs of business.

“ITIL describes procedures, tasks and checklists that are not organization-specific, used by an organization for establishing a minimum level of competency. It allows the organization to establish a baseline from which it can plan, implement, and measure. It is used to demonstrate compliance and to measure improvement.” (Wikipedia)
Compared with an enterprise architecture program is designed for each company to maximize the competency of the company, ITIL aims at setting minimum checklist which can be applied all organizations. 
 
 

Currently many major companies applies ITIL to increase efficiency their business. For example, The Walt Disney Company(TWDC) has started to adopt ITIL since 2008. Glen Taylor, VP of Technology for Theme Parks & Resorts (TP&R), led the TP&R’s ITIL initiative to move towards an integrated service management approach with ITIL best practices. TP&R is the largest division in the organization, which generated approximately 30% of TWDC’s revenue in 2009. The mission of IT in TWDC is 100% availability, reliability and maintainability in order to provide their guests with “the perfect experience”.
“It means we have to ensure that widespread change does not result in incidents; that we are sure-footed and confident with our release management and new capabilities. We also need to ensure we manage our outsourcing contracts with the utmost professionalism. ITIL best practice provides these assurances." (Disney's ITIL® Journey Case Study)
However, change of business in real world is not a simple way. One of major obstacle is not a technical problem; rather it is in human side.
“Where I talk about best practice and ITIL integration, at the start of the process, the staff only know how we do business. They are unaware of both ITIL and our interest in it. The first step is to make them aware of our interest.” (Disney's ITIL® Journey Case Study)

Anthony Orr, Global Best Practice Director and Senior ITIL Examiner, BMC points out that the most important factor in adopting ITIL is people.


 

"There are several constraints with adapting ITIL or utilization of ITIL. The major constraints are really found around people. In order to be successful ITIL, it requires executive involvement, management commitment, and individual contributor commitment. At the end of the day, the really constraints for these people are education."

As IT systems became necessity for the society, many frameworks and methodology including EA frameworks and ITIL have been developed. From many successful case studies, we can know these practices are useful. However, most important factor that determines success and failure of IT project usually seems to be in human side rather than technology or methodology side.

20 Nov 2012

eGovernment

As well as the movement of Enterprise 2.0, governments are trying to make a maximum use of capability of internet technologies. Wide-ranging application can be considered.

Jeong Chun Hai classified the e-Government delivery models as follows:*1
  • G2C (Government to Citizens)
  • G2B (Government to Businesses)
  • G2E (Government to Employees)
  • G2G (Government to Governments)
  • C2G (Citizens to Governments) 
Especially, G2C (Government to Citizens) is most important model considering the role of governments, and internet technologies can make substantial contributions in this field. Nowadays many governments around the world run their own website for provide their services.

Building website is not everything. Recent advancement in technology provide further capability of high quality and low cost services to governments. Keeping up with technology can offer governments more opportunities to improve their IT platform.

One of these cases is the websilte of federal government of the U.S. USA.gov. Using innovative technologies enable governments to provide better services at low cost. For example, USA.gov significantly cut the cost at significant level by using cloud platform for their website.

"Deputy Associate Administrator of The Office of Citizen Services, Martha Dorris, has estimated that the move to Terremark’s cloud platform will cut costs by 90%, while improving capabilities with the newfound infrastructure flexibility." *2
Also, in other areas, enthusiastic discussions are held involving not only public sector but also private companies such as IT and contusing companies. In 2010, O'reilly held gov2.0 summit in Washington, where major IT companies including Google, IBM, Microsoft, and people from government got together.


What is the future of eGovernment. Let's have a look at near future visions provided by governments. European Commission shows its action plan between 2011-2015 on the website. There are four main categories in this action plan as follows:

We can know that an eGovernment aims at more than just providing governmental services and information to their citizens. For example, in the "Empower citizens and business" section, there is a description as follows:
"Other crucial milestones to focus on are" ... "effective means enabling the active involvement of citizens and businesses in the policy-making process based on newly available technologies."
This message shows they consider that IT enable a new form of policy making process in a few years. In this sense, IT cannot be consider as just a technology, rather it need to be considered along with governmental strategy.

References:
*1 http://en.wikipedia.org/wiki/E-Government
*2 Case Study: USA.gov Achieves Cloud Bursting Efficiency Using Terremark’s Enterprise Cloud

19 Nov 2012

Enterprise 2.0 with CMS

A content management system (CMS) is a web publishing platform which allows editors to create, edit, upload and modify contents. CMS usually has user-friendly GUI, so that uses need not know about systems on which the CMS is running.Today, many of public organization including government use CMS for building their websites.

The following link is the list of CMS used by government in the U.S.
http://www.howto.gov/web-content/technology/agency-cms-products

There are several products on the list such as:
These tools provides strong capability for users to manage contents and publishing them on the Internet. CMS is also used as an online collaboration tool. Users can allocate roles for other members and define the workflow depending on their rules.

Well, if it can be used for collaboration, why don't we use it for information platform inside an enterprise. These kind of ideas occurred in 2000s when a word "Web2.0" became popular. In 2006, Andrew McAfee, a professor of Harvard Business School, coined "Enterprise 2.0", which describe the way to use Web2.0 technologies for intranet and extranet of an organization.



AIIM (Association for Information and Image Management) defines Enterprise 2.0 as
"a system of web-based technologies that provide rapid and agile collaboration, information sharing, emergence and integration capabilities in the extended enterprise."
(http://www.aiim.org/What-is-Enterprise-20-E20)
At first, these discussions were abstract. The meaning of the concept itself is discussed. Several tools such as blogs, tagging, social bookmarking, etc, are proposed as tools for Enterprise 2.0. Also, some risk factors such as security issues are discussed. The word might sound like just a buzz word which would disappear in short time at that time.

However, as many people realized the value of Web 2.0 tools, several companies tried to use these tools for their business. Now, we can find many case studies online, and many companies are still engaging in this field. For example, E2 is a conference for Enterprise 2.0, which is held twice a year in the U.S.


Recently, Enterprise 2.0 issues become exciting filed connected to some hot topics such as big data, cloud, BYOD, and so on.

As a tool for Enterprise 2.0, CMS will not just a contents publishing platform. In fact, some CMS has functions such as  e-commerce, data analysis, etc., which might not be imagined in the past. CMS will acquire more functionality along with evolution of Enterprise 2.0.

References
http://en.wikipedia.org/wiki/Enterprise_2.0
http://www.cio.com/article/123550/Enterprise_2.0_Definition_and_Solutions

12 Oct 2012

EA Frameworks

When you consider using EA, where you start from? There are many things to consider when you develop an enterprise architecture. Scott A. Bernard shows six core elements which are required for complete EA approach:

  • Governance
  • Methodology
  • Framework
  • Artifacts
  • Standards
  • Bestpracticies



Especially, a framework have a important role in terms of providing tools for developing EA, and various frameworks have developed and evolved.

History of EA Frameworks (Wikipedia)
Most common frameworks are following four frameworks:
Each of these framework has its own strength and weakness. So, enterprise architects are required to choose appropreate tools fit for the project. Understanding the characteristics should be useful.

The Zachman Framework is the oldest enterprise architecture framework and still is useful tool. The Zachman Framework is rather a "taxonomy" than a "framework" for organizing architectural artifacts. So, it is useful to identify which artifact should be developed on a certain situation. However, the Zachman Frame work doesn't show any process to develop an enterprise architecture.

TOGAF, on the other hand, shows the process to develop an enterprise architecture. The most important part of TOGAF would be its Architecture Development Method (ADM). Since, Zachman and TOGAF can complement each other, they are often used in combination.

FEA is a more ambitious and complicated framework. It attempt by the federal government to unite a lot of agencies and functions of government under a single common enterprise architecture. FEA inculudes both a taxonomy and a process of an enterprise architecture. FEA is a comprehensive framework, but more complex than others.

Gartner is rather unique approach compared to other frameworks above. "It isn't a taxonomy (like Zachman), a process (like TOGAF), or a complete methodology (like FEA). Instead, it is what I define as a practice." Perhaps, it would be difficult to generalize and to apply Gartner Approch. It seems like an art based on Gartner's knowledge rather than a framework.

A number of other frameworks are exists. However, none of these frameworks is a "correct answer". Every project has different characteristics. So, what is important is selecting, arranging, or even creating a framework for each project.

These frameworks are not just "a fancy staff". The value of  them are significant, and more companies become to have interest in these thihgs.
"Judging by the growing interest in enterprise architecture and the proliferationof frameworks, such as TOGAF, DoDAF, IAF, and EAF, the benefits are real." *1
However, business people actually may not understand these tools, or EA program. "business executives often consider the cost of implementing enterprise architecture as dauntingly high and see the business benefits as elusive and risky. "*1

The value of frameworks may not be admitted by business people. David F. Rico shows a metrics to quantitatively evaluate the value of enterprise architecture program. You can see amazing number of value such as 4418% of ROI. These numbers are attractive for corporate executives. Also, EA frameworks need to show such a quantitative value to attract business people.

References:
*1 http://www.ibm.com/developerworks/rational/library/enterprise-architecture-resistance/enterprise-architecture-resistance-pdf.pdf

26 Sept 2012

Are EA projects worth the price?

What are values of an Enterprise Architecture (EA) project? It might be a difficult to explain the value of EA in a word or two. However, responsibility for explaining its value lies on enterprise architects, and Anne Lapkin, Research VP of Gartner, says they haven't fulfilled their responsibility.
"Most enterprise architecture teams do really bad jobs of explaining value of enterprise architecture to the business. " (Anne Lapkin)

She points out that following points are required for enterprise architects to communicate the value of EA.
  1. To understand your value prepositioning in terms of what you are delivering to your business.
  2. To set up a formal communications discipline to be able to communicate that value to the business and to your other stakeholders.
  3. To put in place some concrete measurements so that you can actually demonstrate that you are delivering value to your business.
So, how can enterprise architects explain the value of EA? One of possible explain is as follows.

One of well known reason of IT Project failure is lack of communication between business people and IT people. Enterprise architecuture (EA) solve this problem analyzing an enterprise from the coordinated views of the entire enterprise. Also, EA help to improve project-planning, dicision-maiking, risk-management, and etc. Well, is it too abstract? Say it is true, how much it is worth? Even only IT systems cost too much for many companies; do EA projects deserve additional investment?

It depends. EA gives us comprehensive view of current and future enterprise state from a view point of unique combination of strategy, business, and technology. On the other hand, creating an EA can consumes a lot of time and money. Thus, if the benefits from creating EA will not outweigh the cost, a company should not invest on the project. However, in some circumstances, creating an EA project will provide long term benefit to the company. Let's see some examples.

InfoWorld's Enterprise Architecture Awards is a showcase of successful EA projects.
In the case of Singapore Ministry of Education, they achieved to reduce a lot of duplicative functions using SOA approach. During the project, the EA Committee reviewed every business cases and architecture. As a result of the IT system renovation, "the organization could respond with agility to the evolving education land scape and its changing policies" and "The Ministry has reduced the number of systems in needs to maintain and support by 44 percent, saving over $25 million through economies of scale".

These cases show that EA actually provide values for some projects, and its impact could be huge. Of course, these projects are the most successful cases and the value of EA varies by the project. The important thing is that enterprise architects need to understand the value of EA for each project from the aspect of business (not only in terms of IT), and tell their clients its value. These best practices above would help to identify the value of EA.

19 Sept 2012

Why so many IT Projects fail?

In January 2012, Japan's Patent Office(JPO) announced that a project which aimed at renovating patent management system resulted in failure.
"Asahi reported that Japan’s Patent Office(JPO) decided to terminate their patent management system renewal project which began in 2006. They already spent 5.5 billion yen(US$70 million) and specially formed inspection committee in the organization recommended to stop the project." (asajin.com)
They must have enough resources to develop software. In fact, they spent enough time(already 6 years), money(5.5 billion yen), and human resources(best software and consulting companies).

Why on earth even such a resourceful project can fail?

Mr. Hagimoto, who worked for the government for a certain period of time in the project, analyze the cause of failure as follows.
  1. The users rely on a leap of faith in IT without specifing how to use the system
  2. The users did not fully analyze their workflow
  3. Inadequate project management both in the vendors and the users
  4. The vendor took the main role for analyzing the user's business process
He also points out business custom in Japanese IT industry, which is the relationship between system integratior(SIer) and a user company. (Publickey [Japanese only])

However, failure in IT project is not unique to Japan. In fact, a lot of IT projects result in failure every year: 10 Biggest ERP Software Failures of 2011.

Robert Frese summarize several kind of reports about success and failure in IT project. Surprisingly, according to a report, 70% of projects were not successful.
"The disturbing conclusion from this Standish report is that only 16.2% of projects were successful by all measures, and that of the 70% of projects that were not successful, Over 52 percent were partial failures and 31% were complete failures." (PROJECT SUCCESS AND FAILURE: WHAT IS SUCCESS, WHAT IS FAILURE, AND HOW CAN YOU IMPROVE YOUR ODDS FOR SUCCESS?
So, is an IT project naturally fated to result in fail? How can we increase the success rate? Based on Mr. Hagimoto's review, at least we have the space to improve following points.
  • Defining project goals and objectives
  • Stakeholders' expectation management
  • Business analysis
  • Project management
You may notice that all of these factors are not problems of software. These are basically organizational or human problems.  I don't know whether EA was executed in this project, but if EA wolud have been used adequately, the success rate might have increased to a certain degree. This is because EA deal with whole range of issues in an enterprise, and also it emphasis on human aspects of an IT project.
"Enterprise architecture is as much about people and social interaction as it is about processes and resource utilization. Understanding each of these aspects of an enterprise is essential to the development of accurate views of the current architecture and relevant, meaningful views of the future architecture."
Scott A. Bernard: "An Introduction to Enterprise Architecture"  

Give it some thought with EA3 Cube Framework. Patent management is one of the enterprise's business segment. "Defining project goals and objectives" and "Stakeholders' expectation management" seem to be mapped "Goals & Initiatives" layer. Business analysis would be mapped over multilayer, which might be mainly related to "Products & Services", "Products & Services", and also "Systems & Applications".  "Project management" is eliminated because it is not about an enterprise itself and has relationship with whole process of the project.
(* This is just a personal viewpoint and may not be a correct answer.)

Each vertical layer is composed "components" and each components contains substantive "artifacts", which are usually documents of analysis, requirement, design and so on. So, if they had broken down the each component, they would have crystallized some solution in the shape of artifacts.
 "Defining project goals and objectives" also defines business and organizational model after the new IT system is implemented. In other words, it defines the "future architecture" of the enterprise. Since goals and objectives are the most fundamental parts of the IT project, it will be difficult to success without clarifying them.
I can't provide detailed analysis here without any precise information about the project, and I know that the reality is not so simple. However, seeing the reasons of failure in the JPO's project, still I can't help but think that EA might have helped the project to be successful, especially in early stage of the project.

12 Sept 2012

Introduction to Enterprise Architecture

"the EA is holistic and serves as an umbrella or "meta-context" for all other management and technology best practices."
Scott A. Bernard: "An Introduction to Enterprise Architecture"
When I hear about Enterprise Architecture for the first time, I was surprised that it covers broad areas of theory including strategy, business and technology. Also, application range of EA cover a lot of ground. It can be applied as documentation methodology, management program, standardized policy, and etc.

EA offers us some useful frameworks to visualize image of an organization and its information systems. The image below is one of such a tools, which is called "EA3 Cube Framework".


The EA3 cube shows changiable business units. So, we may analyze a company and divide their business into functional business modules with this framework.

In a thesis, "The Trouble With Enterprise Software", service-oriented architecutre (SOA) is propoed as a solution for developing flexible and effective enterprise software. The thesis also point out that "most companies are in the early stages of a four-part transformation to SOA". EA3 will be a helpful tool to achieve this transformation.

What is interesting for me in learning EA is that I can acquire an overhead view of IT systems in an organization. I have worked for several years as ERP software developer, but I have not learned about EA. When I see this cube, I can recognize where I used to be. Perhaps, I was mainly working in "Systems & Applications" layer (also related to Data & Information and Networks & Infrastructure layers). This notion gave me a comprehensive viewpoint on an enterprise, which will enable me to design better information systems.

Another famous model in EA is the Zachman Framework. This framework is composed of matrix, which shows appropriate tools for various situations in enterprise. The rows of the matrix are layers in an enterprise ranging from executive perspective to technician perspective. The columns shows 5W1H (What, When, Where Who Why, How).

This model also gives us birds-eye view of the enterprise architecture.

Then, what is the relationship between UML, which is familiar diagram for engineers, and Zackman Framework. Is UML a part of Zackman? Well, It seems not. Zackman Framework seems only shows abstract instruction for each situations, and not mentions any particular tools such as UML. These diaglams are independently developed for different purposes.

However, some people says to understand interrelationships between diagrams will give us advantages in developing IT systems. Gundars Osvalds proposes an example of combination of Zackman Framework and UML, where UML is used to define the implementation of the architectual model in Zackman Framework. Also, Vitalie Temnenco shows examples of collaboration of Zackman, UML, RUP (the Rational Unified Framework).

These case shows some of frameworks are vary flexible, and we can choose some of them depending on the purpose. In this sense, we may say frameworks are like "vocabulary" of enterprise architects. If we learn many frameworks, we may expand range of solutions. On the other hand, if we only have poor "vocabulary", the range of solutions will be limited.

Also, enterprise architecture is an ever-improving field. Since, EA covers both of technology and business filed, it need to be updated when a new technology appears.

In 2011, Forrester announced a report named “The Top 10 Technology Trends EA Should Watch: 2012 To 2014″. The list is as follows.
  1. Elastic Application Platforms Emerge.
  2. Platform as a Service Crosses the Chasm.
  3. Data Services, Virtualization Reach Critical Mass.
  4. Holistic Integration Enables Agile Enterprises.
  5. Social IT Becomes Enterprise Plumbing.
  6. Improved Virtualization Sets Stage for Private Cloud.
  7. Always On, Always Available Is the New Expectation.
  8. Network Architecture Evolves to Meet Cloud Demands.
  9. Personal Device Momentum Changes Mobile-Platform Strategy.
  10. ‘App Internet’ Ushers in the Next Generation of Computing
(Source: http://horizonwatching.typepad.com/horizonwatching/2011/12/forrester-top-10-trends-in-enterprise-architecture.html)

As the same as another IT related filed, EA need to catch up with these quickly changing trends.

Nowadays, the presence of enterprise architecture has became larger. Enterprise architecture is widely adopted by major companies. Basant Mehta, Strategist of Hewlett Packard, says that any of the fortune 500 companies has separated enterprise architecture group.

(Source: YouTube)

The evolution in IT and business will make EA a fundamental activity of management of an enterprise.