Professional Development Series

A couple of weeks ago I wrote the first in our series of professional development blogs highlighting industry associations that enterprise architects should consider joining (see here) . Among them was IASA, the International Association of Software  Architects, which also offers a year-long mentoring program for professionals who want to grow their expertise in a particular capability such as enterprise, business, software or information architecture. Also on the menu are programs that are industry-specific, or related to a skill or next-generation technology such as security and service-oriented architecture (SOA).

The discovery of this list came shortly after I received an email from my high school: It’s starting an Alumnae Mentoring program to help students interested in similar careers work toward their goals all the way through their college years.

This got me thinking: Do most enterprise architecture practices offer mentoring to staffers? As I recently wrote here, I think it’s very important to encourage the participation of younger architects in projects in a more holistic fashion. But I focused on why that’s good for you and your efforts, not how it helps the company and the staff. As Jeanne Ross, Director and Principal Research Scientist at the Center for Information Systems Research at MIT, recently told us, it’s important even for those lower down in the architecture food chain to spend time with those whose processes they are trying to affect. “They will start to design simpler things if they can start to understand the essence of the issue,” she noted. (For our interview with her, see this blog.)

Giving Back and Paying Forward

Here, I’d like to focus on giving back, or paying it forward — whichever interpretation you prefer — and not just to individual staffers but to the company that (we hope) you’ve been proud to represent. Toward that end, I talked about the value of a mentoring program and how to develop one, with Badar Munir, Chief Architect at i3 Technologies Inc., which provides management consulting services in business architecture, enterprise architecture (EA), organizational change, business transformation and process improvement. In Badar’s architecture consulting engagements, he’s had experience mentoring personnel who would run the EA practice after he left.

One important result from creating some type of formalized mentorship effort is this, Badar says: that home-grown and nurtured talent will be ready to step into the shoes of departing senior EA professionals. He says, “In bigger companies — especially if they have more complex enterprise architectures — they keep looking for people from the outside.” But why?  Going outside means they haven’t built a base of solid strategic architects to promote from within even if they have technical talent.

The goal, of course, is to ensure that future enterprise architects are business leaders and strategic thinkers first, not primarily subject-matter experts in a narrow area of focus. Says Badar: “An organization should establish and [develop] an EA program to achieve strategic benefits. [These benefits] may include achieving higher levels of business agility, improving ROI on IT capital investments, developing better insight into IT and business strategies [and/or] improving IT/business alignment.”

Steps to a Mentorship Program

So how do you  establish a mentorship program at your company — one that will not only affect junior architect staffers but also those who’ve perhaps had longer careers in roles such as project and program management?

Here are some thoughts from Badar, who recognizes that there can be two levels of mentorship efforts;

• The first level focuses on developing a core EA training and communication program. “Provide this training to all resources whose projects will be audited or monitored by the EA team,” so they are prepared for their roles and deliverables from EA perspectives for all incoming projects. That means selected individuals, from project managers to solution architects to senior business analysts, are provided training regarding the company’s EA framework, its standards, components and goals. They are also trained about the EA governance process. 

• The second type of mentorship identifies individuals to become future senior enterprise architects. “For mature EA shops, I recommend that chief architects establish such a program within their practices. As a matter of fact, it should be part of their EA maturity model,” he says. In his experience, it’s wise to consider as mentoring candidates not just individuals with hard skills such as program and process management, and information and infrastructure architecture adeptness. Soft skills, he says, are important, too — which means considering as candidates those individuals who are people-savvy, who respect the company’s culture and values, who are both analytic around total cost of operation and return on investment issues, and who have shown an understanding of business strategy and business models, he says.

• Promising candidates can be identified through project participation. “For those you think you want to move up in the future, look for one or two of the soft skills — when you talk to them about IT or business strategy, how do they react?” he says. “Do they ask more questions, or do they remain in their technical domain and keep talking about how cool the technology they support is?” Be prepared for those coming from technical architect roles to struggle in the soft -skill areas in different ways.

• The career ladder for IT architects may include moving them from project architect to solution architect to enterprise architect, as they acquire soft skills and experience interacting with the EA group to develop an understanding of the organizational EA practice, he says.

• Project and program managers, he suggests, can be selected for EA management roles based on their personality and expertise in areas such as process development and management, and strategy and governance skills. These, he says, “will be critical for them to succeed in the EA group.”

Has your company thought about developing an EA mentorship program? If so, let us know how it got its start and how it’s going today.

Professional Development Series

Last fall the Association of Enterprise Architects (AEA) — originally founded by the Open Group back in 2007, but now a separate not-for-profit organization — announced that its membership exceeded 20,000. Enterprise architects from 72 countries count themselves among its members. Upon reaching this milestone, Association CEO Steve Nunn had this to say:

“Industry demand for developing Enterprise Architecture as a profession has been the impetus behind the surge in membership and displays the commitment that practitioners, as well as their employers, are making when building their Enterprise Architecture strategy.”

But just as membership in the AEA reflects the growing demand by enterprises to embrace the discipline of architecture and profit from the standardization and integration it brings to the business, it also reflects an understanding by architects that it’s to their own benefit to join. Professional associations and organizations provide a forum to engage in discussions (online or live) about critical issues with like-minded individuals and contribute to industry efforts. They can be a pathway to educational and career opportunities; members may hear about possible jobs through their association networks long before they’re posted on Monster.com. And these associations promote and advocate for the profession in which you are invested. 

With all of this in mind, Smart Architect is kicking off what will be a regular series of blogs on professional development with a look at some of the associations you may want to investigate to further your profession’s interests as well as your own. Here are few to get you started:

Name: Association of Enterprise Architects

Membership: The primary professional membership level is its Member grade, which is open to a TOGAF® or Open CA certified Enterprise Architect. Fellow-grade membership is open to applicants who have five years’ AEA membership under their belts, and who hold a senior enterprise architect position. Other membership options also are available for those working toward TOGAF or Open CA certification and students.

Mission: AEA’s goals are to increase job opportunities for members and increase their market value by advancing professional excellence, and to raise the status of the profession as a whole. Only Member- and Fellow-grade members may join task- or issue-oriented work groups aimed at helping to advance the profession.

Name: Center for the Advancement of the Enterprise Architecture Profession (CAEAP)

Membership: Interested individuals must read and sign the Enterprise Architect's Professional Oath, which CAEAP describes as a social contract for moral behavior, commitment toward the community, and mutual obligation among members and the enterprise architecture profession itself. The oath is a guideline for shaping the behavior of EA professionals and for stating the consequences of misbehavior.

Mission: CAEAP says it promotes the professional status of enterprise architects, including clarifying the contributions of professional enterprise architects and creating brand recognition for the profession. It is also interested in advocacy about determining ethical behaviors and levels of regulatory self-governance, and educational and experiential standards for professional competency.    

Name: The International Association of Software Architects http://www.iasaglobal.org/iasa/default.asp (IASA)

Membership: Individuals can enroll as full, student or contributing members, at varying fee levels.

Mission: The International Association of Software Architects (IASA) makes its match with architects committed to the advancement and sharing of issues related to software architecture in the enterprise, product, education and government sectors. It wants to advance best practices and education while delivering programs and services to IT architects of all levels.  

Name: ISACA

Membership: Membership levels include professional and student at varying fee levels, and complimentary membership for academics in certain functional disciplines.

Mission: While not exclusively directed to enterprise architects, the independent, nonprofit, global association has a focus on practical guidance, benchmarks and other tools for the IT-enabled enterprise in areas that intersect with EA interests, including governance and security. Some of its brands include the Risk IT governance framework and the Certified in Risk and Information Systems Control (CRISC) certification for helping the enterprise understand business risk.

Name: Association of Business Process Management Professionals International (ABPMP)

Membership: Professional, academic and student memberships are available at different fee levels. Corporations also may join. Only professional and corporate members have voting privileges.

Mission: A practitioner-oriented and practitioner-led nonprofit, ABPMP hopes to guide the development of business process management as a mainstream discipline and serve as the authority for certifying BPM practitioners. While it, like ISACA, is not specifically geared to enterprise architects, it does count them among its members, including its Metro New York Chapter president. It makes sense, given the value that can come from combining EA and BPM in the service of architecturally enabled enterprise change that draws on improved, aligned and even automated processes.

This is just a starter list, and one focused on memberships that individuals themselves can join. If your organization wants to be part of an association whose interests align with enterprise architecture, corporate membership is available to organizations such as The Open Group, whose standards and certification programs for enterprise architects have been adopted worldwide, and Penn State’s Center for Enterprise Architecture, where partnering organizations can have early access to research and reports, exposure to undergraduate students interested in the discipline and the chance to sponsor their EA capstone projects, and the ability to influence the future of enterprise architecture education at multiple levels (undergraduate, graduate and professional education).

We’re sure there are many other professional groups that you’ve found invaluable in your own career, and we invite you to share your thoughts on what those are and how they’ve contributed to your own success. We also welcome your comments on any of the associations mentioned in this blog – what has been your experience as a member? Let us know below.

Storage is critical enterprise infrastructure, and how best to protect these environments to ensure the safety and recovery of the data that resides there is pretty darn important. But is this sometimes a bit overlooked by enterprise architects thinking more about big-picture strategies than nitty-gritty details?

Perhaps. Consider, for example, that physical to virtual infrastructure transitions present the best chance nearly any organization will have for some time to rearchitect its backup methodology, says Marco Coulter, Research Director for Storage Practice at TheInfoPro (a division of 451 Research). After all, a large-scale change like that doesn’t happen every day. You have to “exploit that opportunity, because you may not get it again for another 10 years,” he says.

Yet, when laying out the frameworks for physical to virtual infrastructure projects, most enterprise architects won’t have a ready answer about accomplishing backup redesign, he says. That has to change: Just as enterprise architects have a role in helping simplify server environments, so too should they play a part in reducing management overhead — i.e., the cost factor — for data protection. “This is a way of protecting the business; it’s not the business,” Coulter notes. “The time you spend doing this isn’t creating business value.” Yet, according to Storage Study Wave 15 done in 1H2011 by TheInfoPro, backup remains the largest storage time-sink (see chart below).

Complexity has had a long reign when it comes to storing, managing and protecting data, going back to the days of purely physical environments. Without guidance from enterprise architects, the addition of virtualization, on- and off-premises clouds, and SaaS solutions, can further complicate data management and protection — certainly during the period of time when organizations are transitioning to these new technologies and environments.    

David Liff, VP, Global Marketing, at CA Technologies, sees the enterprise architect as bringing the risk assessor’s eye to the job, to apply recovery point objective (RPO) and recovery time objective (RTO) principles appropriate to each specific business process, across whatever swaths of technology are in place or moving into place, and ideally enabling all protections via a single ergonomic console. “Architecting storage used to be about making sure you had enough storage and that it was working. That’s now a given,” he says. “Now it’s about driving risk management around storage architectures, based on the business process defining RPO and RTO.”

The amount of data the enterprise is willing to lose and the amount of time it is willing to wait to recover information depends on the impact that each specific loss-and-recovery effort will have on the business. It may be okay to lose a day’s worth of human resource transactions and to wait two weeks to recover HR data, but clearly it’s a very different story for the transactions and data involved with online trading system processes, for example. There, the requirement may be to restore back to just one minute or one transaction ago, and to do it instantly. While storage architects are themselves being asked to think more about protection according to RPO and RTO objectives, they should be defining those SLA goals in consultation with enterprise architects, Liff says.

Indeed, the enterprise architect should make it a point to be involved now more than ever. After all, enterprise architects regularly deal with governance issues, and increased regulatory and legal requirements — such as producing digital records in a timely manner as part of electronic discovery of evidence during litigation — demand good storage architecting and data protection practices. 

The enterprise architect also is needed now, more than ever, to help guide backup and recovery strategies because the enterprise has to move away from using many technology solutions to manage and protect distinct environments — physical, virtual, cloud — to a solution that can range across these platforms and across their various vendors, while seamlessly accommodating different business process Service Level Agreements. “That’s a challenge that creates churn,” Liff says. “Storage is known for high levels of complexity, and in large organizations you have teams of experts running different solutions, but their expertise is not portable. These teams are passionate about what they do and emotionally attached to what they know, too. Once you get to the business-driven goals of RTO and RPO, you need someone who’s outside of just the storage world — the enterprise architect — to decide what is the way forward to a more comprehensive solution that gives you granular control at a very high level.” (Today there are just a very few solutions that fit the bill, including CA Technologies’ ARCserve, he says.)

However you’re contemplating addressing storage in the new year, Coulter makes an important comment about getting these architectures right, especially in light of all the work most enterprises have been doing around server virtualization and the growth in capacity that that’s been driving. “Get it wrong and you will spend more and more on storage, and that eats into the savings [virtualization can deliver] on the server side,” he says.

How are you planning to help your enterprise get storage right? 

I’m sure you’ve heard comments like these before: “How do I prove my value to the organization’s leaders? Why don’t they understand what enterprise architecture really enables for the business?”  Well, opportunity’s knocking to change all that.

You will recognize it by the Big Data overcoat it’s wearing.

You know that oft-quoted statistic that humans use no more than 10 percent of their brain power? It turns out that the enterprise effectively uses less than 5 percent of its data power. That means there’s a whole lot of data there that’s not being maximized to drive business revenue or cost-savings. The enterprise architect who can help align the infrastructure and processes so that the organization can do more and get more out of its data — delivering real, tangible results that senior leaders can “touch and feel,” so to speak — is the enterprise architect who will get the recognition he or she so richly deserves.

Clearly, you and your colleagues, businesses, agencies and the IT industry at large are thinking about this (have a look at the article Big Data Proliferation Requires Big Solutions here). In my last blog, for example, I talked about some of the skills prospective employers expect enterprise architects to bring to the job-market table, and increasingly one of them is expertise in dealing with Big Data. Consider also the attention being paid to the relationship between Big Data and enterprise architecture at big industry conferences. The Gartner Symposium ITxpo 2011 touted sessions for enterprise architects such as Big Data for IT/OT: Integrating Real-Time Data Into Decisions, for instance. And the Hadoop World 2011 conference also featured its own enterprise architecture track, whose topics include how the open source Apache Hadoop project is being used to build real-time big-data services at Facebook, and how companies can bridge the gap between data warehouses and Hadoop to extract business intelligence from large, heterogeneous data sets. 

Research firm Forrester — the minds behind that 5 percent estimated data use figure — also has been all over the role enterprise architects can play in helping the organization boost its data returns, including taking thought leadership roles on the importance of a holistically approached information architecture and the need to assess applications’ integration of knowledge through service-oriented architecture (SOA), business intelligence (BI) and other mechanisms. But the usual approaches and implementations of these capabilities may well require revisiting. In his blog, Forrester Principal Analyst Brian Hopkins has noted that Big Data “will require new processes and may totally redefine your approach to data governance.”

The why for making changes such as those Hopkins describes is tied to the fact that now we’re not just talking about making sense of a lot of data. That’s been happening around historical data and predictive analytics for a long time. The why lies in the multiple aspects of Big Data that Forrester and other analyst firms are talking about. Call it the four V’s of volume, velocity, variability and variety, as Forrester has. Or, apply its attributes in any acronym you prefer, such as SVA-US (scale, volume and acceleration — structured and unstructured, including rich media and social media data), maybe, or VCS (volume, complexity of data types, and speed). The end result is the same. Traditional data warehouse and business intelligence systems can’t affordably keep up with making sense of the deluge, in real time, across diverse formats and in unpredictable ways. Nor do those tried-and-true approaches necessarily lend themselves to the increased interaction with data by more business users.

Here are just a few of the projects I’ve heard about that help illustrate both the complexity of getting value from so much data that so relentlessly enters the enterprise in so many forms, and the concrete value of moving in this direction:

• A major bank has a project under way to use everything from transaction data to audio files from service calls with customers to improve its ability to get a true picture of what happens in fraudulent cases and to better detect fraudulent occurrences. 

• One large health insurance firm has to deal with data from internal and external sources sprawling across in-patient, out-patient, pharmacy, finance and cost-management groups, for analysis of everything from treatments to demographics to lab tests, in order to provide decision support that lets doctors and nurses choose the best course of care. 

• Tracking social media — talk about a wild, wooly and unstructured Big Data space! — made it possible for one firm to identify influencers in its area and then to send marketing messages outlining its solution’s benefits to those whose messages it deemed might have an impact on their followers.

What’s needed to conquer such oncoming challenges and realize emerging successes is someone to champion a new way forward, to architect a vision around Big Data. That vision, I’d think, needs to be an expansive one, inclusive of things like direct interaction with data assets by the business and dynamic information discovery. That champion should be YOU.

How’s Big Data knocking at your enterprise’s door, and what’s your strategy for answering the call? Share your stories with your peers here.

Imagine having to manage your personal computer the way you manage the distributed servers in your data center…

• Instead of simply purchasing and installing apps that perform the useful functions you want, you have to laboriously piece each one together component by component and integrate and secure them yourself, or engage professional services consultants to do it for you over weeks (or more) while you struggle to still use your computer for other useful work.
• Instead of just launching each app you want to use, you have to first specify how much CPU, memory, disk space, and network capacity you are going to allocate to it — and not just maximums, but how much will be consumed all the time (and if your demand spikes to more than those fixed amounts, all kinds of trouble from service degradation to crashes will ensue).
• Instead of blithely launching additional apps as you need them, you have to manually rebalance the allocation of capacity to all your other apps to make room for each additional one.  After all, capacity can only sum up to 100%.
• Instead of only running each app you want to use for the period of time you need to use it, it is so hard and takes so long to allocate and de-allocate resources and to start and stop apps that you have to keep them all on all the time.
• Instead of your operating system dynamically tracking your attention and use of the multiple apps you have running at any one time, bestowing the most capacity upon the one you care about most or that is working hardest to provide its services, all your apps are always consuming whatever invariant portion of the resources you gave them when you launched them, needed or not, and even though you have only one "in front" on your desktop and are working intensely with it, it can only limp along using the fraction you gave it when you launched it.

These are just a few of the ugly and awkward differences between the experience we enjoy on our personal computers (and, yes, our individual servers and mainframes), where the operating system and user interface dynamically manage the prioritization and allocation of infrastructure resources to what we care about most — our applications — almost completely without requiring us to think about capacity or demand, and the harsh typical enterprise IT management reality.  When I think about how I use my computer, I am sure that my IT-enabled productive use of it would be severely hobbled -- at least a 10x hit -- if I had to be as aware and engaged in the constant minutia of managing and allocating every type and level of my computing infrastructure and the assembly and deployment of every application.  We're probably talking about at least 10x more cost for 1/10th the utility, and let's not even try to estimate the difference in agility. 

In my personal IT world, all I really care about are my applications and the services they provide.  The software that manages the starting and the stopping of those apps, the dialing up and down of resource allocation, and the sharing, separation, and prioritization of access to fixed real hardware capacity does so seamlessly, invisibly, and in a manner so responsive to my shifts in attention and demand that most of the time I am not even aware of its operation.

Imagine what it would take to approach that level of intelligent and dynamic automation of our distributed enterprise infrastructure management, of having the luxury of application-oriented management that responded to and optimized for business service needs instead of requiring the hammering of applications to fit the static and manually-administered infrastructure mold.  That's what we've been thinking about at CA Technologies, and we're planning to share some of that thinking with you during the "Cloud Agility Architecture" segment of the Smart Architect session at CA World.  Hint:  It's more than virtualization, more than what we think of as automation today, more even than "cloud", though all three of these are important prior art. 

Bring your use cases and be ready to contribute your feedback.  This is our imagination at work, but we're serious about making it a reality.

IT leaders should never underestimate the extent to which the poorly coordinated application of advanced technology can destroy civilization.

Harmony doesn’t come naturally to implementing complex concepts such as virtualization and the cloud. It must be orchestrated, and that calls for the CTO and senior enterprise architect roles to align and intersect. A harmonious arrangement is especially warranted for building and automating virtual environments. Applying new, advanced technology requires an agreed-upon technical strategy and reference architecture. The CTO and the chief architects are responsible for defining both. Implementing the strategy/reference architecture occurs through the governance and technical leadership – the mapping of the whole into its constituent parts – which the enterprise architect function delivers.

Think of it as the CTO and enterprise architecture (EA) team together composing the score so that everyone involved in winning the virtualization war knows how to perform his or her part.

Virtualization, after all, is not a narrow technology. Virtual machines running on a virtual OS are just the start of the equation. All systems are layered and interconnected. The broader infrastructure software — application servers, enterprise service buses, database systems, etc — enables composite applications. (Any non-trivial application is a composite application.) The virtualized hardware begins a continuum that stretches to composite applications. Virtualization, then, should be seen as a contract between an artifact — any artifact — and something that knows how to do something with it.

Some examples are:

• Java runtimes virtualize Java applications.
• J2EE application servers virtualize web applications.
• Relational database servers virtualize data schema and operations on the data.

And increasingly, organizations want that something to happen in the cloud. The cloud virtualizes where the artifact interpretation occurs. An enterprise can map elements of the composite application and software infrastructure to infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), programmable web APIs and software-as-a-service (SaaS). The result is a cloud-spanning, virtualized business services. (see Figure 1. A Cloud-Spanning, Virtual Application.)

Figure 1.A Cloud-Spanning, Virtual Application

So, the artifacts — and the composite apps to which they contribute — must map to the things that know how to run them across internal and external environments. That mapping is accomplished through automation, and the automation process should be designed with modeling tools. Modeling tools vastly simplify defining the cloud-spanning business service, and replace:

• Endless meetings, whiteboard drawings and PowerPoint presentations.
• Complex, tedious manual tasks to configure and deploy application artifacts.

Making Good Things Happen

When the CTO and senior enterprise architects have a strong and collaborative relationship, successful use of new technology is possible. As CTO — now at CA Technologies and previously at other organizations — there are dozens of details that I have entrusted to my senior enterprise architects. Other CTOs can apply the same approach to provide depth to virtualization reference architecture, making the high-level concepts they  consider real.

The architects make the concepts in the technical strategy and reference architecture concrete enough to implement. For example, cloud-enabling an application is not possible without security, which requires the deep domain expertise of security architects. Security must occur consistently through all aspects of the solution, which is the role of architecture governance. The enterprise architect is critical to determining how each domain fits into the whole virtualization reference architecture. The architects also coordinate themselves and the organization through concrete models, which are essential to coordination. For example, there may be requirements for enterprise architects with expertise in automation to be paired with an architect with expertise in security. 

Modeling and architecture can also form the foundation for collaboration between technologists and business stakeholders. A new role is emerging: the “bridge architect.” The bridge architect is an enterprise architect who speaks the languages of both business and technology, and who can use intuitive models to ensure precise, concrete realizations of the business goals via IT. Consider, for example, that every time the enterprise uses a cloud service, it needs to create a contract concerning fees, service delivery and quality of service. That will lead to an increased need for architects who understand and can design these services into billing systems, roll them into reports and help the enterprise truly exploit new levels of agility.

Assess the CTO-Enterprise Architect Relationship

Virtual stall is an increasing problem in enterprises. Applying virtualization yields positive initial results, but increased use of virtualization does not deliver additional improvements. Architecture-independent application of virtualization is the cause of stall. A more devastating, and likely, outcome is an environment that doesn’t work at all.

So, the challenge I have for CTOs and enterprise architects who want to avoid this is: How good is your relationship? From the CTO’s perspective, you can’t be afraid to surround yourself with smart people with strong opinions. Part of the job of the enterprise architect is to push back, and making a CTO think harder about his or her own approach usually winds up being better for the organization. Enterprise architects are bright people. If they have reservations about what you’ve explained or how you’ve explained it, you should revisit the discussion.

I also think CTOs should view themselves as being a true part of the architecture team. While you ultimately make the final decision, more important is to realize that you are first among equals.

Finally, here’s hoping that CTOs and enterprise architects everywhere enjoy what they do. The way I see it, you’re having fun only if you’re doing something hard and scary, such as building your virtual, automated IT environment.

Let me paraphrase President John F. Kennedy when he spoke of going to the moon. He said we choose to do such things not because they are easy, but because they are hard. We choose to do them because the goal serves to organize and measure the best of our energies and skills, and because that challenge is one that we are willing to accept, and to win.   

John Zachman has been saying the same thing for a few decades now: Enterprise architecture should not be about building and running systems, but about engineering and manufacturing enterprises. The founder of the Zachman Framework continues to say that today. And the recent revision to the Zachman Framework speaks even more truth to that power.

The latest evolution of the Zachman framework was released in late August, and it has in its sights more descriptive representations of enterprise assets, so that the business can better deal with complexity and extreme rates of change. To help set the stage, it’s useful to know that Zachman considers his to be an ontology framework, meaning that it provides the structure for organizing information. As explained on the Zachman International web site, an ontology framework prescribes “the existence of a structured set of essential components of an object for which explicit expressions is necessary and perhaps even mandatory for creating, operating, and changing the object (the object being an Enterprise, a department, a value chain, a “sliver,” a solution, a project…)” and so on. So, it is the foundation the enterprise architect requires to act upon any of the methodology frameworks, such as TOGAF.  Methodology without ontology, Zachman told Smart Architect, is alchemy, not science.

Fundamentally, the changes were designed to more precisely articulate what artifacts (any tangible asset, such as a document, that contributes to an architectural description) are required for describing a complex object. “So this version of the framework is just one more step — and probably a major improvement” to what has gone before, Zachman says. “This is a better articulation of classification concepts, of the schema,” he says.

Also, the revision recognizes that the audience for the framework is changing. “The audience 30 years ago was mostly made up of technical people. The audience really for this, is the whole enterprise.”

The basics stay the same, in that the framework still is based on a classification of descriptive representations in two dimensions. The first dimension is centered on answering six questions to achieve a complete description of a complex entity – i.e., the enterprise (see graphic above):

• What is it made of (the data, the business objects)?
• Why does it exist, for example, in terms of goals or business plan?
• How does it work regarding things such as business processes and application functions?
• Who holds various responsibilities and what are their relationships to one another?
• Where are the entity’s location sites and their interconnections?
• When are events scheduled and accomplished?

The second dimension has to do with reification, which involves transforming the idea of an entity into a result through the contributions of those invested in the outcome.

The Zachman Framework continues to follow, the principles that any other architectural discipline follows to construct an entity, whether that entity is an airplane, a building or the enterprise.   

More Need than Ever for Enterprise Architecture

There is some urgency in the revised framework’s focus on choosing words to more accurately describe its classifications for a more general audience — without, of course, sacrificing technical precision. There’s little runway left to get a general management audience to begin to understand conceptually what is going on in the enterprise, so that they can make the decisions and trade-offs necessary for it to succeed, Zachman says. “The name of the game today is extreme complexity and extreme rates of change,” he says. “The complexity today vs. 20 years ago is out of sight, and it is just the beginning. The same [is true] for extreme rates of change. So [if an enterprise is] to survive in the long term, you had better do architecture, whether you like it or not.” 

As Zachman notes, enterprise architects must create engineering design artifacts to instantiate whatever demand the business is trying to accommodate. Not only that, but if you want to change something after it’s built — and with the extreme rates of change characteristic of business today, chances are that you will —those engineering design artifacts are required as the basis for those changes. Otherwise, the business will spend time and money recreating what it’s already got or tearing it down to build it all anew. 

As an example of what the revision holds, Zachman explains that the framework’s data column, with its system-level view of what entities comprise an enterprise, isn’t necessarily clear to general management. “Enterprises couldn’t care less about entities — what they do care about are inventories, which are what they must manage to keep assets from leaking,” he says. Call the information in the column of data models inventory sets instead, and you’ve given the business stakeholders the “ah-ha” moment they need. Or consider the network column and its focus on enterprise geography and interactions among locations. To the generalist, the location model indicates building address, but what it should indicate, and now does, is the enterprise’s distribution networks (whether those networks are for raw materials, finished goods, or voice and data).

Zachman says that there’s opportunity to be harnessed, by architects with their heritage in IT, when it comes to embracing the paradigm of engineering the enterprise that is even better reflected in the framework’s revision. Though he’s been talking about architecting the enterprise and not just building isolated systems for a long time, it’s still a radical concept, he says, But perhaps it’s also one that will carry more weight in the profession with cloud computing’s rise and the prospects it offers the enterprise of outsourcing even more technology operations. “I submit that the reason the enterprise needs IT people is because what we bring to the table are the drafting skills, we know how to describe things and how to build models,” he says.

For years, the default has been “to write some code and get things implemented,” he says. The problem, however, is that “we’ve got legacy, all kinds of implementations and applications that are not integrated, flexible, interoperable and reusable. [We’ve got] applications that are not engineered but implemented.” He’s encouraged that this approach is changing, though, and that a growing body of thoughtful people in the IT community now really get the idea of the engineered enterprise.

The clock is ticking, and a lot faster than it used to be. Says Zachman: “The reason to do architecture for anything — and specifically for the enterprise — is because of complexity and because of change.”