Approach to EA at Fujitsu and Relationships Between EA, SDAS, and SOA

Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

V Hiromi Matsuyama (Manuscript received March 13, 2006)

Enterprise Architecture (EA) is an increasingly popular system that totally optimizes business and information systems by IT governance and adjustment of business and information strategies. The EA used at Fujitsu has features such as 1) an approach for realizing IT governance, 2) early development support of EA, and 3) smooth coopera- tion for operation and further development of EA. Our EA receives good reviews by providing a practical EA methodology in the form of a development and consulting service. From the viewpoint of System Development Architecture & Support facilities (SDAS), Fujitsu’s EA is not only positioned as an entry point that connects a business strategy with system requirements analysis, but also deeply incorporates the concept of SDAS into its methodology. This paper outlines EA, Fujitsu’s approach to EA, and the relationships between EA, SDAS, and Service-Oriented Architecture (SOA).

1. Introduction “enterprise-wide optimization” to quickly respond Enterprise Architecture (EA) is gaining to changes in the social environment and chang- attention as a mechanism that can totally es in information technologies. It organizes and optimize business and system operations by stra- systematizes business processes, information tegically aligning management strategies with system structures, and technologies to be used by information strategies and realizing IT gover- putting an entire organization into perspective. nance. EA is not only an upstream phase that In Japan, EA was first adopted by the links management strategies to System Develop- government in the autumn of 2002 for the ment Architecture & Support facilities (SDAS), improvement of e-government procurement pro- which is an integrated system development cesses. Then, in 2004, the government assigned methodology developed by Fujitsu, but also has a assistant Chief Information Officers (CIOs) to close relationship with SDAS from the viewpoint individual government agencies as EA promoters of smooth linkage with the development phase. to develop EAs for all projects relating to infor- This paper outlines EA and then describes mation systems by the end of fiscal year 2005. Fujitsu’s approach to EA and the relationships In addition, EA started to be applied in the with SDAS in the EA building process. It then private sector, centering largely on private enter- describes the interrelations between EA and prises facing a rapidly changing business Service-Oriented Architecture (SOA). environment, for example, automobile, electron- ic, and finance enterprises, and enterprises facing 2. Overview of EA a reorganization of their industry. Nowadays, the EA is a structure for improving business accelerated pace of change in business makes it operations and systems from the viewpoint of difficult to build systems to suit management

286 FUJITSU Sci. Tech. J., 42,3,p.286-294(July 2006) H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

strategies. This trend has diverted the attention document form. Although they are the most im- of industries to EA as a mechanism for portant part of an EA, enterprises as well as appropriate investment and enterprise-wide IT government agencies are often unaware of their governance. It is believed that the application of importance. It should be noted that it is difficult EA will become an important issue that every or- to develop principles as one expects them to be, ganization and enterprise must consider. but that if consensus cannot be formed during the process of developing principles, the EA will be 3. Fujitsu’s approach to EA reduced to a dead architecture over the long term. 3.1 Definition of EA structure by Fujitsu 3) Architecture models There are a variety of EA frameworks. Architecture models are prerequisites for an Fujitsu defined a practical EA structure by EA. For the construction of specific IT systems, further improving the EA frameworks of the design and development will be implemented Japanese government, which were modeled after according to these architecture models. Fujitsu the Federal Enterprise Architecture Frameworks has divided them into the following four tiers (FEAF) of the U.S. (Figure 1). This structure based on the architecture models of the Japanese was also made public and was generally accepted. government. The following explains the six pillars of EA. • Business Architecture (BA) 1) EA governance • Data Architecture (DA) EA governance realizes basic control for • Application Architecture (AA) or Service implementing enterprise-wide optimization. All Architecture (SA) EA activities will be implemented under this EA •Technology Architecture (TA) governance. Organization-wide EA governance is These four tiers are described (modeled) with normally promoted by the information depart- respect to the As-Is model (or baseline architec- ments and the planning and development ture), which models current operations and departments of organizations, but dedicated teams systems; the Target model (or best practice), which are often formed for its promotion. presents improved operations and next systems; 2) Principles and the To-Be model, which represents the future The principles are the mission of EA put into (or ideal) state with the time base taken into account. 4) Reference model This model is referenced when generating 1) EA governance architecture models. Its content can be a set of 2) Principles best practices, the results of investigation of the

3) Architecture models current state, or the projection of a future state. PRM As-Is Target To-Be The Japanese government has published the BRM following five reference models. DRM

SRM BA BA BA •Performance Architecture (PRM) TRM DA DA DA • Business Reference Model (BRM) 4) Reference AA AA AA • Data Reference Model (DRM) models TA TA TA • Service Reference Model (SRM) 6) Transitional processes •Technology Reference Model (TRM) 5) Standards With the exception of PRM, which is a set of models for assessment indicators, these models Figure 1 Structure of Enterprise Architecture. correspond to individual architecture models.

FUJITSU Sci. Tech. J., 42,3,(July 2006) 287 H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

5) Standards EA structure cannot be uniformly determined, The standards are technical and institution- attention is particularly focused on establishing al rules and standards that should be referenced the EA building process. in EA activities. Some examples of these stan- dards are the development standards, data 3.2 Fujitsu’s concept for EA building definition standards, security policy, and opera- process tion management standards. The EA building process varies, and it is 6) Transitional processes not clearly defined even in the EA of the Transitional processes are the processes Japanese government. After study, Fujitsu divid- required to make a system operational and are ed the EA building process into five phases based on the current operations and IT system. (Figure 2). The wider the introduction area of a target The EA building process starts after a vision organization becomes, the more difficult the plan- and mission based on the management environ- ning of possible transitional processes becomes. ment have been developed and confirmed. In the In general, the processes targeted for putting the EA building cycle, individual phases are next system into operation are collectively called implemented in sequence to form the cycle of an implementation plan. plan-do-check-act (PDCA). For an EA structure, its specific content and 1) Phase 1: Developing principles points of importance vary depending on the In this phase, principles that constitute rules current state, strategy, mission, and goals of the for promoting an EA are developed and, if neces- target organization. Because the content of an sary, the area to be optimized by the EA is

Vision and 1. Development of principles mission • Set principles • Determine areas to be optimized/principles

EA framework 1) EA governance 2) Principles

5. EA maintenance and 3) Architecture models 2. Architecture development PRM improvement As-Is Target To-Be BRM • Develop architecture models • Assess EA DRM • Develop reference models SRM BA BA BA • Review EA TRM DA DA DA • Develop standards 4) Reference AA AA AA • Establish EA models TA TA TA 6) Transitional processes 5) Standards

4. Next system construction 3. Transitional processes 4. Next system construction • System4. Next design system construction development • • stemSystem development design • Develop transitional processes • System design • •Test/commissioning System development • Create target artifact • System development • Test/commissioning • Create RFP • Test/commissioning EA governance

RFP: Request for proposal

Figure 2 EA building process.

288 FUJITSU Sci. Tech. J., 42,3,(July 2006) H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

determined. Because it is difficult to introduce to the EA from model changes that have been an EA from scratch to an entire organization or made during development can lead to EA mainte- system, the often-adopted approach is to introduce nance and improvement. EA to a smaller area and then extend it according Each phase is composed of several steps, to the results of the introduction. while EA governance controls the processes as a 2) Phase 2: Developing a main architecture whole. EA governance refers to a standard for In this phase, architecture models, reference assessing the levels of improvement and also models, and standards are developed. When refers to management and control throughout the developing architecture models, the following are entire cycle. described: business operations and processes for BA (top tier); logical and physical data models for 3.3 Fujitsu’s EA promotion DA (second tier); individual applications and their Fujitsu’s EA promotion activities started with inter-relationships for AA (third tier); and the its participation in the EA model project of the network infrastructure, middleware, and hard- Ministry of Economy, Trade and Industry (later ware of an IT platform for TA (bottom tier). handled by the Ministry of Internal Affairs and It takes a huge amount of time and work to Communications), which started in the autumn completely develop reference models and stan- of 2002. This project continued until the end of dards. Instead of developing them from scratch, 2004 as a key project for determining the EA the examples of other enterprises can be refer- guidelines of the Japanese government. A large enced or existing reference models and standards number of organizations participated in this can be improved after their assessment and project, including Fujitsu, and some of the partic- modification as the EA implementation proceeds. ipants were especially involved with a study on 3) Phase 3: Developing transitional processes reference models. The results of this project were In this phase, transitional processes are used, for example, by Fujitsu to create its own developed for moving from the developed As-Is TRM. In addition, in July 2003, Fujitsu released model to the Target model and the To-Be model. Japan’s first EA service. The service, called the In many cases, only the To-Be model is developed Administration System Optimization Service, has in Phase 2 and a possible Target model is devel- been successfully applied to a variety of business oped in Phase 3 considering the transitional situations. processes in this phase, and then the Request For For human resource development, which is Proposal (RFP) is created based on the resultant a prerequisite for EA promotion, Fujitsu started product. Therefore, the RFP creation phase three internal EA training courses in the autumn overlaps the definition of requirements in of 2003 to train 400 employees. Then, in 2004, development. Fujitsu started providing customers with a two- 4) Phase 4: Building the next systems day practical course that evolved from that In this phase, individual systems are devel- training and has received favorable responses oped. Fujitsu’s integrated system development about the course. Furthermore, in collaboration methodology SDAS is utilized in this phase. with an NPO organization, ITC-METRO,1) from An EA is not visible in this phase. 2005, Fujitsu started providing education for IT 5) Phase 5: Maintaining and improving the EA coordinators using Fujitsu-version textbooks. In this phase, the EA is maintained and Through the above activities, to establish an improved through feedback from the results of EA methodology in which Fujitsu’s collective development. Although the Target model substi- strengths can be fully utilized, Fujitsu compiled tutes the As-Is model after development, feedback manuals (SE handbooks) by combining its expe-

FUJITSU Sci. Tech. J., 42,3,(July 2006) 289 H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

rience in the projects of government agencies by enterprise activity and the characteristics of using the SDAS modeling technique and other Fujitsu’s EA that are based on this position tools and methodologies with which Fujitsu has (Figure 3). expertise. Based on this methodology, in July 2004, Fujitsu announced a consulting service 3.4.1 Position of EA in enterprise activity called Business and System Optimization Consult- When strategically aligned with each ing. Fujitsu responded to about 100 inquiries other, a management strategy for responding to regarding this service and subsequently won about changes in the management environment and an 30 subscriptions. Because enterprises pursue IT strategy for coping with the IT evolution will returns on investments, EA development tends to contribute to enterprise-wide optimization. The be considered an excessive burden. For this role of EA is to control the enterprise-wide reason, when conducting business, it is necessary optimization of business operations and systems to understand each customer’s particular situa- by acting as an intermediary between informa- tion and propose a practical way of introducing tion systems and such a strategic alignment. The an EA. Fujitsu’s EA is intended to serve exactly EA components include, first of all, principles, this purpose and is also distinctive on this point. then architecture models visualized from these principles, standards for controlling and making 3.4 Characteristics of Fujitsu’s EA architecture models efficient, control organization This section describes the position of EA in and rules for running the entire EA smoothly, and

Changes in Management IT strategy IT evolution management environment strategy

• Build IT responding to changes in Strategic • Build new business models through business with flexibility alignment full utilization of IT

Enterprise-wide optimization of business operations and systems/IT governance

Principles Architecture Standards As-Is To-Be Business Business Business IT environment environment model model Transitional Visualization Control/ • IT standardization • Process processes (modeling) Data model Data model efficiency • Operation • Information standardization • Organization/ Application Application • Assessment rule IT infrastructure IT infrastructure standard

Control organization and rules, IT investment management

Systemization requirements (Functionality, operation) Monitoring Building Operation Development Application Assets Application maintenance Platform Operation and IT infrastructure IT infrastructure construction maintenance

Figure 3 Positioning of EA in enterprise activity.

290 FUJITSU Sci. Tech. J., 42,3,(July 2006) H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

finally IT investment management. As can be Fujitsu attempts to realize seamless cooperation seen, EA is a powerful mechanism for IT gover- between EA and tools and methodologies for nance. Thanks to the above role of EA, development and operation such as SDAS and further-optimized system requirements can flow TRIOLE using documentation and templates to into the building phase, whereas EA can be make them consistent. In particular, as shown in improved by receiving monitoring information Figure 4, Fujitsu’s version of TRM arranges from the operation phase. domains in place so they can connect as is to the However, if viewed from a different angle, EA infrastructure platform of TRIOLE. placed in such a context is equal to the activity of improving the total development of existing sys- 3.5 Decreased management risk by EA tems, which requires a huge amount of time and In recent years, we have seen leading investment. Consequently, while acknowledging companies that were pioneering new markets with the beneficial effects of an EA, many enterprises their excellent business models have their foun- are reluctant to introduce it. dations shaken and their brand images degraded due to security problems such as personal data 3.4.2 Characteristics of Fujitsu’s EA leakages and system failures caused by computer Fujitsu’s EA has the following characteris- viruses, and there seems to be no end to such tics that help to quickly and efficiently produce occurrences. Furthermore, since the Anti Data effects based on the above realities. Leak Law was enacted in Japan, security prob- 1) Provision of a method of realizing IT lems have become a serious management risk. governance To prevent security problems, not only indi- Fujitsu formed an organization for promot- vidual preventive measures need to be made ing IT governance throughout the entire Fujitsu available on information systems, but also inter- Group and provided guidelines on IT investment nal control needs to be put in place over entire management to promote IT management inside information systems. “Internal control” means a the Group. Based on the experienced gained as a framework built for reducing the occurrence of result, Fujitsu can provide a very effective frauds and errors that hinder the achievement of method of realizing IT governance. business objectives pursued by an organization 2) Support for rapid development of EA and for reducing their impact when they occur. An EA methodology was developed based on Fujitsu thinks that to establish internal control Fujitsu’s experience in EA development. Through over information systems as a whole, the intro- this methodology, Fujitsu helps customers to rap- duction of an EA, which helps obtain an overview idly develop an EA by standardizing the process of information systems from the viewpoint of of EA building and making it efficient. In addi- enterprise-wide optimization, will become man- tion, as a methodology for the rapid introduction datory. Specifically, internal control mechanisms of Phase 2’s To-Be model, which is difficult to de- will be applied to entire information systems velop, Fujitsu developed a consulting technique indirectly by standards, guidelines, and decision- called “Short EA” based on Executive Planning making processes that are clearly defined in an Guide (EPG), which is a mission-oriented plan- EA. ning technique developed by Fujitsu. In addition, it is important to ensure 3) Seamless cooperation with development and compliance with laws and regulations for operation reducing management risk. In the U.S., the An EA serves no purpose unless it seamless- Sarbanes-Oxley Act of 2002, born of the lesson of ly cooperates with development and operation. the Enron business scandal, mandates enterpris-

FUJITSU Sci. Tech. J., 42,3,(July 2006) 291 H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

Application software Business package Application Business-by-business and Business Content LoB-by-LoB framework data LoB solution

Application development Development environment Application Development standard platform (Development support platform software (Platform frameworks) environment)

Service platform Presentation Security Service Shared system service Operation & management Channel Information management service service service • Authentication • Monitoring • Encryption system System platform Network service • Operation system Platform service

Hardware Platform, network equipment

Figure 4 Framework of Fujitsu version TRM.

es going public on the U.S. stock market to put in ed at the same time. Fujitsu strives to upgrade place and assess internal controls. Also in Japan, its EA methodology so its EA can be a basis for the Japanese version of the Sarbanes-Oxley Act the above activities in the future. is scheduled to be enacted in 2008, and the intro- duction of internal control audits to ensure its 4. Relationship between EA and implementation is also scheduled. Enterprises SDAS listed on the stock market are now seeking ways EA is concept-driven; it does not specify of responding to this act. To respond to internal particular methods or tools. For this reason, control audits, the introduction of an EA is most customers attempting to develop an EA are con- effective because control over an entire informa- fronted with the question of how and what to start. tion system and control over individual Therefore, when implementing the EA building applications must be made transparent to process, Fujitsu recommends to customers an EA auditors. into which SDAS tools and methodology are It should be noted that the Committee of effectively incorporated. We would like to stress Sponsoring Organizations of the Treadway that the concept of SDAS pervades Fujitsu’s EA Commission (COSO)2) framework published in methodology. 1992 in the U.S. is often used for presenting From the SDAS side, however, EA is posi- how internal control should be. As shown in tioned as an entry point that connects Figure 5, to make internal control effective, this management strategy and system requirements framework requires that the three elements of risk analysis. It is necessary, in particular, to use the assessment, control, and monitoring be repeated EA entry point in cases where, prior to the analy- continuously and that the control environment, sis of requirements on individual systems, information, and communication affecting these company-wide consistency must be considered and elements be properly established and implement- a grand design for a To-Be state must be created.

292 FUJITSU Sci. Tech. J., 42,3,(July 2006) H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

handled by today’s enterprises are serious chal- Management risk reduction lenges in the development of an EA because a huge amount of time and human resources are needed

Internal control over entire information systems in place to cover all the relevant information. In order to solve this problem, SDAS provides Control a business data modeling technique that adopts environment Risk note) EA introduction assessment the concept of Kaname Analysis. By using kaname entities and kaname events, which are Definitions of standards Information Guidelines and Decision-making process, etc. communication described in the paper, “Use of Business Model- ing in Requirements Definition Phase,” elsewhere Control Monitoring activities in this special issue, we can clearly distinguish main parts from accessory parts, thereby clarify- Figure 5 ing an IT system’s structure. This improves Reduction of management risk by EA. efficiency in the DA model phase. 2) Phase 3: Developing transitional processes Transitional processes for moving from the developed As-Is model to the Target model and EA and SDAS thus complement each other very the To-Be model are developed in this phase. It strongly. should be noted that it is not easy to develop pro- The following describes the contributions of cesses because of the huge number of existing SDAS in the EA building process, by giving systems. Fujitsu provides the TransMigration examples of two deeply related phases. Services based on its know-how of rebuilding 1) Phase 2: Architecture modeling systems with flexibility while effectively utilizing In EA, modeling is performed across the four existing systems. The diagnosis phase of this tiers from BA to TA. Fujitsu’s EA gives an exam- service provides investigation and analysis meth- ple of the modeling artifacts shown in Figure 6. ods such as asset analysis for analyzing available Workflow diagrams are mainly used in the assets and Proof Of Concept (POC) for verifying BA model phase. However, after collecting spe- the validity of transitional methods. By applying cific examples, we found that modeling is these methods, transitional processes can be sometimes adversely affected due to differences developed that are more efficient and present in the personalities of the modelers because 1) the fewer risks. descriptions are inconsistent because there are no conventions for creating them and 2) there is no 5. Relationship between EA and procedure for the modeling work. SOA Therefore, we applied a business process Fujitsu released a solution structure based modeling technique, “Valuevision Modeling Meth- on SOA in July 2005. From the EA side, general- odology (VMM),” provided by SDAS for generating ly speaking, SOA can be recognized as a models that provide the information stakehold- methodology optimized in SA. However, if ers need to reach a consensus about system conceived as business data modeling and business development, while minimizing the personality process modeling for realizing services aligned influence of people generating the models. with the concept of SOA, SOA should be described In the DA model phase that follows, the essential problems of an enterprise are identified. note) “Kaname” is a Japanese term that means a nail or the point where the ribs of a The complexity and magnitude of information Japanese fan are secured.

FUJITSU Sci. Tech. J., 42,3,(July 2006) 293 H. Matsuyama: Approach to EA at Fujitsu and Relationships between EA, SDAS, and SOA

Definition of requirements Design

Data flow Workflow Entity Information diagram diagram relationship systems Fujitsu’s EA (DFD) (WFA) diagram functional artifact (ERD) configuration • • • • • • diagram

(SA02) (SA02) (UI05) (SS01) ComponentAA Business Business Table Use case Development functionality functionality relationship functional Method outline definition outline definition diagram • • • configuration • • • (Business (Systematization overview flow) workflow)

Figure 6 Seamless cooperation with EA artifacts. as the basic concept that pervades the architec- infrastructures. The EA approach is effective for ture modeling of EA. meeting these needs. Fujitsu developed and is EA and SOA will continue to improve and testing an infrastructure optimization grand evolve, interrelated with each other as essential design called the EA/OPENframework as a approaches that should be considered when methodology for realizing these needs. Moreover, constructing a change-tolerant IT system. we hope to develop a more effective EA approach by strengthening the linkage with SDAS. 6. Conclusion This paper introduced EA, Fujitsu’s approach References to EA, the relationship between the decision pro- 1) IT Coordinators Association. (in Japanese). http://www.itc.or.jp/index.html cesses of EA and SDAS, and the relationship 2) The Committee of Sponsoring Organizations of between EA and SOA. the Treadway Commission (COSO). http://www.coso.org/ In recent EA business, there have been many requests for the application of an EA approach to the optimization of infrastructures. To achieve Hiromi Matsuyama, Fujitsu Ltd. this, it is necessary to have a viewpoint that is Mr. Matsuyama received the B.E. degree in Information Engineering from long-term and intended for enterprise-wide Kyusyu University, Fukuoka, Japan in 1977. He joined Fujitsu Ltd., Tokyo, optimization when considering the optimization Japan in 1977, where he has been of infrastructures and operations. It is also engaged in research and development of EA at Fujitsu. He is a member of the necessary to ensure long-term usefulness of Japan Society for Systems Audits (JSSA). application assets, which are separate from

294 FUJITSU Sci. Tech. J., 42,3,(July 2006)