Coherency Management

Dr. Scott Bernard is the founding editor of the Journal of Enterprise Architecture and teaches at Syracuse University and Carnegie Mellon University. In 2004 he wrote the book An Introduction to Enterprise Architecture that presented the ‘EA3 Cube’ architecture framework, the ‘Living Enterprise’ repository design and an associated implementation approach. Dr. Bernard has over 20 years of experience in IT management, including work in the academic, government, military, and private sectors. He has held positions as a Chief Information Officer, management consultant, line-of-business manager, network operations manager, telecommunications manager, and project manager for several major IT systems installations. Dr. Bernard has developed enterprise architectures for public, private, and military organizations, started an EA practice for an IT management consulting firm, developed his own consulting practice, and taught EA at a number of universities, businesses, and agencies. He holds a Ph.D. in Public Administration from Virginia Tech (2001); a M.S. in IT Management from Syracuse University (1998); a M.A. in Business Management from Central Michigan University (1984); a B.S. in Psychology from the University of Southern California (1977), and a CIO Certificate from the U.S. National Defense University (2000). Dr Bernard can be reached at sabernar@syr.edu.

JEA: When and how did you get involved in Enterprise Architecture?
Bernard: I can actually remember the moment that the concept of Enterprise Architecture became clear in my mind as something of great importance. In early 2000, I was attending courses to earn a “Chief Information Officer (CIO) Certificate” at the National Defense University’s Information Resources Management College in Washington DC and I enrolled in a class on Enterprise Architecture (EA), thinking that it was something that CIOs should know about. Carolyn Strano was the instructor, and as an early proponent of EA she covered general concepts and several approaches including those from John Zachman, Steven Spewak, the C4ISR (which became the Department of Defense Architecture Framework – DODAF), and the Federal EA Framework (FEAF) that was just coming into use in the government. In one class session, when Carolyn presented the graphic of Zachman’s 6×5 framework, the idea of EA as a meta approach for the documentation of many types of enterprises became clear to me… it was my “aha moment.” At that time I was the Director of Network Operations for the Joint Chiefs of Staff at the Pentagon and in that position, as well in several previous IT management positions in the U.S. Navy, I often had to deal with IT operating environments that consisted of dozens of siloed programs and systems. What we lacked was coherency via an over-arching EA that could provide useful, coordinated views of all of the systems that were in the operating environment, as well as standards for program offices to use in developing and operating systems in the current and future environments. Since then, I have used EA often when I worked for several years as a management consultant and most recently as the Deputy CIO at the Federal Railroad Administration in the U.S. Department of Transportation. To me, EA is the meta approach that organizes strategic, business, and technology planning and decision-making, and is an essential part of organizational governance. EA has graduated well beyond its early roots in IT, and its potential to serve as the “big umbrella” for all other management and technology best practices is unique and important for executives and managers who struggle to choose which practice(s) to follow.

JEA: What is the current state of EA in the U.S. Federal Government?
Bernard: EA remains an important element of business and technology governance for U.S. Federal Agencies. It is still mandated by law (the Clinger-Cohen Act of 1996) for all Federal Agencies to do and has since been implemented through guidance issued by the Office of Management and Budget (OMB – which is part of the Executive Office of the President); audits, maturity models, and best practice recommendations from the Government Accountability Office (GAO – which reports to Congress); and private sector best practice examples that the agencies may incorporate into their EA implementation approaches. EA, as it is currently practiced in the federal sector is comprised of the Federal Enterprise Architecture (FEA) that is used for architecture analysis and reporting; and several approaches to modeling and documentation (the FEAF and DODAF) that are endorsed in OMB Circular A-130 and in the publication “A Practical Guide to Federal Enterprise Architecture” that was produced in 2001 by the Federal CIO Council. The FEA is administered through a Program Management Office at OMB and consists of five reference models (performance, business, service, data, and technology); three profiles (security/privacy, geospatial, records), and a number of practice guidance publications (e.g., how to implement service oriented architecture, and how to do segment-level architectures).

JEA: How well do you think the legislative approach has worked so far for the US?
Bernard: My own opinion is that unfortunately it often takes a law or OMB-level guidance to cause U.S. Federal Agencies to adopt new methods of managing their programs and resources to improve mission capabilities. Other countries have government cultures that allow for these changes to primarily occur through collaborative interaction. That said, there is no debate about whether or not to do agency architectures – which is an accomplishment in itself. Yet, agency EA programs to date have had a mixed record of success in terms of improving mission capabilities, with some agencies showing a number of measurable accomplishments (e.g., support for business transformation, outsourcing, social networking, and the implementation of new technologies). Perhaps the greater success of EA has occurred at the general level of the Federal Government through OMB-led program reviews and support for various “Line of Business” initiatives that without the influence of EA would not be possible to pursue in a standardized way across the dozens of large Departments and their Sub-Agencies, independent Agencies, Boards, Offices, and Commissions (e.g., IPv6 rollout, Identity Management, Trusted Internet Connections, and Infrastructure Consolidation). Also, the development of the EA Assessment Framework (EAAF) over the past several years by OMB has provided a consistent way for agencies to evaluate how EA is contributing to improving mission capabilities. Finally, FEA-generated information is an important part of the business cases (Exhibit 300s) that agencies must submit annually to OMB for their major IT investments in order to get new or continued funding – and this has significantly improved OMB’s program oversight capabilities.

JEA: What were the triggers that led to the development of FSAM?
Bernard: The Federal Segment Architecture Methodology (FSAM) was developed as best practice guidance by the Federal CIO Council in 2007-2008 to help federal agencies be able to create and use architectures at the segment level, versus architectures at the enterprise or system (solution) levels. The impetus for developing the FSAM was a combination of the non-completion and/or under-achievement of a number of enterprise-level agency architectures and an over-focus on systems-level architectures that did not foster enterprise-wide improvements. The FSAM also is intended to promote the development and rollout of new agency services across multiple lines of business by using EA and other best practices such as service oriented architecture (SOA), which in my opinion is a good way to integrate business, data, and application sub-architecture elements for a particular service offering – done within the context of an over-arching enterprise architecture. The 5-step FSAM methodology was published in June 2008.

JEA: What has been your role in the development and release of the Federal Enterprise Architecture Security and Privacy Profile (FEA-SPP)?
Bernard: The FEA-SPP is part of the overall Federal Enterprise Architecture and is intended to provide a repeatable methodology for incorporating information security and data privacy concepts and practices into agency enterprise architectures and security/privacy programs. I have been fortunate enough to co-lead a working group to develop the FEA-SPP with Dr. Ron Ross of the National Institute of Standards and Technology (NIST). The FEA-SPP Working Group is sponsored by the Architecture and Infrastructure Committee within the Federal CIO Council. The heart of the FEA-SPP is the full lifecycle implementation of information security and data privacy controls at the enterprise, segment, and system levels of the agency architecture. This is done through the coordinated use of NIST’s Risk Management Framework, the FEA’s reference models, and the FEAF/DODAF artifact documentation methods. Version 3.0 of the FEA-SPP is scheduled for release in late 2009.

JEA: Do you see an increased interest in the US towards incorporating EA in business school and technical school curriculums, and what are the enablers and obstacles that you observe?
Bernard: Definitely. I am seeing EA courses being taught in various degree programs at colleges and universities around the world, which is quite encouraging. This includes EA courses in undergraduate and graduate degree programs at Schools of Business (the “B-Schools” which in this context look at how to manage business programs/projects and business applications for IT-related technologies); Schools of Information Studies (the “I-Schools” which focus on how people use information and how to manage IT programs); Schools of Computer Science (which primarily look at how information is processed by computers and the design of computer systems), and Schools for Public/Government Administration (which in this context focus on how government agencies use information and how to manage government business and IT programs). The primary enabler for EA to continue to emerge in these school’s degree programs is the recognition that more and more of the core mission/business functions of government and business organizations are dependent on various information technologies, and to properly harness this you need a scalable and standardized enterprise-wide architecture. The primary obstacle is that EA still competes with other strategic planning, business improvement, quality management, and technology management best practices for the position as “the” meta-approach that will organize, relate, and inform all of the other best practices. Until this is resolved (and it may never be totally agreed upon) the picture for faculty and students will continue to be somewhat clouded as EA and various other best practices compete.

JEA: As a practicing-academic what role have you and the groups you affiliate with played in spreading the idea and discipline of EA?
Bernard: I have been very fortunate to be part of a number of new and established groups of a very high quality that have helped to promote the profession and practice of EA. These include the Association of Enterprise Architects (a|EA), the Journal of Enterprise Architecture (JEA), the Institute for Enterprise Architecture International (IEAI), Carnegie Mellon University, and Syracuse University. I use the term “pracademic” to describe the hybrid of practitioner and academic activities that I engage in on an ongoing basis, which seems to be of great benefit for an ‘applied’ area of academic inquiry such as EA (as opposed to purely theoretical areas). To be valid and effective in helping enterprises to be more successful, EA needs both a firm grounding in established theory as well as proven associated best practices that guide implementation of the theoretical concepts. The theory will come from various social and physical sciences (e.g., information, systems, organization, and management-related theories), which for EA is in the very early stages. The associated best practices are already out there (e.g., using the Balanced Scorecard™, using the CMMI™ for process quality, and using ITIL™ for infrastructure service delivery) and the challenge in the near term is to be able to show how to use these best practices in the context of EA. Regarding the promotion of EA as a profession, I have had a lot of fun helping to start a|EA, JEA, and IEAI, as it has provided a way to meet others who are interested in EA around the world and to see the similarities and differences in EA practices in different countries and sectors. Carnegie Mellon University and Syracuse University have provided invaluable help by sponsoring a|EA and JEA, and in developing some of the first EA certification programs and graduate level courses that were top quality right from the start. For me, the work in EA practice, teaching, and writing has been most enjoyable.

JEA: What would be your advice to aspiring enterprise architects?
Bernard: EA is a growing field and it will increase in importance and value to many types of organizations in the business, government, military, non-profit, and academic sectors. The need to be able to coherently understand, model, and analyze complex organizations will grow, as will the need to help them to be effective in achieving important goals in shorter timeframes and within increasingly dynamic global operating environments. This will occur, in part, through having a formalized, scalable, and standardized EA. In retrospect, I wish that I had known about EA concepts when they were first being developed by John Zachman and Steven Spewak during the late 1980s and early 1990s – when I was just starting to manage IT programs – it would have helped me to make sense of a number of otherwise disparate collections of systems and programs. EA is here to stay, and as a profession it will continue to encompass positions at the entry, mid, and senior levels that will provide very competitive salaries and a great deal of job satisfaction. Therefore, I wholeheartedly encourage people who are just starting their careers and those who are already in a career field to consider becoming an enterprise architect as their primary area of practice or as a supporting specialty.