Did you catch the new movement in town: Enterprise Architecture? Well, enterprise architecture is a new term that draws upon information design and management ideas from the past. It could be
called a new way of thinking about some pre-existing ideas around architecture and modeling for IT teams.
Industry leaders have said that IT strategy is one of the primary economic driving forces of a successful company. Out of this comes the ability to centrally manage data and understand what data
you have. To implement standards and methods behind the data. That’s where enterprise architecture comes in. It helps company’s design and implement technology and data on an enterprise level to
drive business strategies and provide a strategic corporate or product competitive advantage.
To get a perspective of enterprise architecture today, I talked with Jan Popkin, CEO and founder of Popkin Software, and a leading advocate of architecture since he founded Popkin 16 years ago.
Popkin Software’s System Architect is positioned as one of the frontrunner products to support enterprise
architecture initiatives.
An Interview with Jan Popkin
Terry Moriarty: What is Enterprise Architecture?
Jan Popkin: Enterprise architecture is a blueprint of a company’s current and future IT infrastructure as derived directly from business goals
and processes. One of the primary purposes of enterprise architecture is to align IT with the business strategy. Enterprise architecture gives CIOs and IT organizations a birds-eye view of how
their technology ties to their strategies across the entire enterprise and helps guide the purchase and deployment of technology. To develop an enterprise architecture, companies use different
enterprise modeling tools, which provide graphical techniques for integrating business strategies and processes, objects, components and data into a single conceptual framework that distills
enterprise information down to the IT systems level for shared development.
Terry Moriarty: Can you be more specific? How does enterprise architecture affect data modeling? Why is it important?
Jan Popkin: Data and data modeling have long been viewed on a project basis. For many years, companies developed data definitions on an isolated
basis because systems were stand-alone. In an enterprise context, enterprise architectures evolved when companies saw a need for systems to communicate and exchange data in a complex
environment.
As the need to integrate data across multiple systems and applications grew, IT managers began looking at corporate metadata or standards for defining data. IT teams saw the benefits of defining
particular business data, so that the meaning could be reused throughout various projects. For example, what does the business mean when it talks about a particular thing like a customer? Is it an
‘Account’ as accounting calls it? Or a ‘Client’ as Sales has labeled it? IT teams saw that data definitions-the use of data, construction of data definitions-could help achieve a level of
consistency throughout the business, saving development time, maintenance and, most importantly, reduce costs.
By using enterprise architecture, data modelers don’t need to design a database from scratch for each project. They establish, then reuse and refine global data definition standards. Metadata-how
the company refers to customer and what is meant by it-can be re-implemented from database to database and data modelers know what it means each time. These standards eliminate the data
inconsistencies that cause endless problems, such as a customer name definition of 32 characters in one database and 48 characters in another.
I think it is more important to point out that one of the benefits of enterprise architecture is that it supports data modeling as a user-defined term. Data modeling in relationship to enterprise
architecture involves lots of different questions in the areas of scaling, scope and interaction with other modeling techniques. Data modeling has a number of roles within an architecture and
companies have to differentiate those to develop the right tools criteria. For example, a database admin would be modeling to keep the physical database schemas up to date while an enterprise
architect would be more concerned with the robustness of a logical data modeling capability, such as the handling of subject area handling or cross-methodology usage of data elements.
Terry Moriarty: Why has enterprise architecture become important again?
Jan Popkin: Ten years ago, enterprise architecture was the mainstay of large, very complex systems where understanding data and its definitions
was critical to the company’s core mission. Corporate systems weren’t typically integrated across the enterprise, especially with global operations. Enterprise architecture is becoming important
again for a few reasons. Data is a vital corporate asset that must be maintained for continued corporate success. Companies are requiring their systems be more integrated across an enterprise to
support a smooth data flow. This includes global operations. Collaboration is a vital business requirement, whether the data is shared internally, with partners or with vendors. The dot-com era
showed us that systems that don’t follow architectural principles have to be discarded-from client server to Web applications to Web services-strike enormous costs, even threatening the business’
existence. Companies see that protecting their data and streamlining their data flows–translating data into a form that all systems can understand and verify as accurate-is a good investment. The
move to distributed data technologies like Web services is another driver.
Let me give you an example of why companies are recognizing the importance of enterprise architecture. A global company can develop a corporate data model and centralize their data definitions into
one standard. The company can use a tool like System Architect to define the data they want and then map the information onto each application. By identifying and fixing these inconsistent data
definitions, a company like this could realize significant cost savings.
Terry Moriarty: What role does a framework play in all this?
Jan Popkin: I always tell people that frameworks are a checklist of what needs to be done to achieve the end result-the architecture. Many confuse
framework and enterprise architecture, but a framework is merely an organizational mechanism for developing an enterprise architecture. Frameworks like John Zachman’s embrace all the aspects of
modeling, from business, IT architecture, business requirements to data. Data modeling is just one of the many columns of checklists in a framework. Frameworks enable modelers to start at the
conceptual level– who needs to see the data, when, and how it is organized–then drill down to detailed implementation plans–how to build a system or application that supports the data.
You introduced System Architect in 1988. For the past 16 years, your focus has been on improving System Architect to become the best enterprise architecture tool in the industry. What evolution
have you seen in tools to meet the changing enterprise architecture?
Terry Moriarty: Enterprise Architecture is getting a lot of attention in the federal government market. Why?
Jan Popkin: When I founded Popkin 16 years ago, I decided that if we could draw the right pictures and choose the right method or process, we
could do better engineering or architecture. This was drawn from my own personal experiences as well as what I learned from Constantine, DeMarco, Boehm and Yourdon as well as many others. At
Popkin, we have tried to build on this philosophy as it evolves. We’ve seen modeling languages, which help developers translate design into visuals, have become more formal and specialized and
achieved a wider acceptance. In data modeling, entity relationship modeling for relational databases theory is well understood and very well accepted. The Unified Modeling Language (UML) has
emerged as the standard for defining code construction, with discussions on what else it can describe. Business process modeling is now becoming a formal, standardized method under BPMI. Each
modeling area of expertise is perfecting its own language and collaborative and communication techniques.
Enterprise architecture helps bring these multiple methods together under a single, centralized architecture that lays out a blueprint for an organization’s information infrastructure. Standards
help promote wider spread acceptance and team collaboration. Other tool features, such as a common, multi-user repository, also help improve communications, information management and data reuse.
Ultimately, enterprise architecture provides a common language for business and IT to communicate, enabling IT teams to design and implement e-business according to global standards. Changes in
business direction can be incorporated into existing systems more efficiently and quickly.
Terry Moriarty: How does enterprise architecture relate to the next wave of technology, i.e. Web services?
Jan Popkin: Architectures will continue to evolve, following the available technology and appropriate business requirements. As corporate American
enters this new era, we are seeing knowledge and intellectual capital emerge as a valuable corporate asset that drives competitive advantage. This is a far cry from mainframes, where technology was
the focus because of its cost. In today’s world, technology is viewed as the means to corporate success, with many companies use the Web as a communication mechanism. The availability of cheaper
computing hardware and software is making distributed architectures cost effective to implement, which is in turn driving the need for enterprise architecture. The need for having a blueprint and
understanding where the data is and where it is distributed has become a lot more complicated. Complex, collaborative systems are driving the need for modeling tools and the visualization
techniques that support building these architectures.
IT organizations with a strong architectural foundation know that technology is a series of waves crashing on the beach. Today it’s Web services, and that will affect tools, languages, processes,
and design, even the architect’s job. But that won’t be the last. Companies that are best positioned to benefit are those that select enterprise architecture over tactical investments. One
analyst group has shown that companies with a strong enterprise architecture are able to adapt to a new technology in one- to two-thirds the time and cost of non-architectural competitors.
Terry Moriarty: Enterprise architecture is getting a lot of attention in the federal government market. Why?
Jan Popkin: Enterprise architectures are growing in popularity as the federal IT environment faces a variety of regulatory and legislative
mandates. First, the recent eGov and Homeland Security initiatives are driving the need for agencies to collaborate and share data. Next, there are a variety of regulatory factors requiring
accountability for IT investment funding. As part of the fiscal 2003 budget, the Office of Management and Budget’s (OMB) A-130 is requiring federal agencies to develop and use enterprise
architectures to show how their IT investments support their agency goals. On the legislative side, the 1996 Clinger/Cohen Act also requires agencies to place more emphasis on pursuing
interoperable, integrated and cost-effective business practices and capabilities within each organization. The act does not dictate how the roadmap be developed or presented, only that one is
required.
Each agency is now in the process of selecting or implementing an existing framework for developing their enterprise architecture or developing their own. For example, the Department of Defense has
developed the Dept of Defense Architectural Framework (DoDAF), previously known as C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance). The US
Treasury has developed the Treasury Enterprise Architecture Framework (TEAF), while the Federal Enterprise Architecture Framework (FEAF) is used by many other federal agencies, such as US
Department of Urban and Housing Development (HUD) and US Department of Agriculture. To coordinate these efforts, all agencies have a CIO,
The business world could actually learn from the federal government on this issue. CIOs at federal agencies seeing firsthand the importance of an enterprise architecture as a way to understand
their current complex IT processes and infrastructure and define a blueprint for the future. They understand that a strong enterprise architecture supports IT evolution. Because they are derived
from agency requirements, IT departments can build stronger, faster and value producing systems that help the agency truly tie technology to agency goals.
Copyright © Inastrol and Popkin, 2002
