The enterprise architect who supplies his or her development teams with custom or off-the-shelf frameworks often eliminates common programming tasks and application requirements. But frameworks can sometimes be too confining, or deliver far more than what’s needed for the project.

This raises the question: What are the ingredients for success in terms of application frameworks, or are they even worth the effort?

There have been cases, such as with Microsoft’s ActiveX Template Library, where a good framework can eliminate a lot of skeleton code that developers would otherwise need to write repeatedly. This isn’t universal, however. For instance, when I first began using Java, some colleagues created a framework to “make it easier to work with this new technology.” It failed because the Java platform was straightforward enough; there was simply no reason to put anything between it and the developer. (Java EE is another story altogether.)

Frameworks: The Spice-Rack Analogy

Joel Spolsky wrote a blog years ago called “Joel on Software.” One entry, entitled, Why I Hate Frameworks, describes the pains of sorting through and reading dozens of feature lists, and draws an analogy to building a spice rack with a “universal hammer.” All too often, frameworks built with good intentions end up forcing teams to conform their project to it.

Research and experience have taught me that frameworks that are an API/library combination with some extras (described below) are generally more successful than those that force developers to conform their programming style to them. Apache Commons, Cocoa, jQuery, Microsoft’s .NET, Ruby on Rails, the Zend Framework and Spring are good examples of this, while Enterprise JavaBeans is considered by many to be a bad one because of its complexity.

What are the qualities an enterprise architect should look for in a framework before setting out to have one built or used in the enterprise? The framework should:

• Provide cross cutter code (i.e., logging).
• Provide skeleton code for reuse.
• Avoid what I call “magic,” or hiding too many details.
• Avoid forcing development paradigms.
• Implement proven patterns (i.e., model-view-controller).
• Focus on APIs.
• Avoid facades that hide other APIs.

However, as enterprise architects, we need not only these qualities but also a more formal approach to framework design and usage.

Role Modeling: A Formal Approach

Frameworks can be described as black-box, white-box, or some combination. Black-box frameworks are usable as is; you simply use the framework API and its objects. A white-box framework is usually a set of interfaces to be extended by your code.

Either way, frameworks need to be integrated into your own projects in some way in order to be useful. This is where trouble often starts, if a framework adds too much complexity, or is too basic to provide any benefit.To help avoid either problem, use the concept of role-based modeling for frameworks. Whether you're building a framework or evaluating an existing one, role-based modeling provides a way to support four important qualities:

1. Separation of concerns: Classes should be distinct, and each class's purpose should overlap as little as possible.
2. Patterns: The implementation of acceptable patterns is key to providing reusable models that are the cornerstone of any framework.
3. Class complexity: This involves understanding and describing how classes interact at the interface level.
4. Object collaboration: This describes how class instances interact at runtime. This goes beyond class complexity, since it mixes in other elements such as data structures, memory usage and persistence.

To address these, role modeling formally describes how one object uses another. In short, an object must take on one of only a few well-defined role types when it uses another object. Role types are similar to class relationships, such as uses, extends or contains, but take into account run-time collaboration as well. Role modeling as a whole describes the collaboration of all the objects in your framework according to their role types. This controls the relationships and minimizes the complexities in your framework, making it easier to learn and extend for future use.

Where Do We Go From Here?

I asked two fellow enterprise architects what they thought about frameworks these days, and their opinions were in line with mine: Frameworks aren’t obsolete, but most organizations often get it wrong when building them.

Why is this? Often it's because frameworks are derived from a successful project and repurposed (often bringing too many characteristics of the original project with it), or designed by committee, with not enough consideration to how they might be used by a family of actual software products.

The consensus among us three is that, in most cases, it's best to find a popular framework that's well documented and successful in the industry, and extend it from there using role-based modeling to ensure usefulness, and avoid complexity.

Where do you stand on the frameworks question?

Consumers flock to app stores to load their devices up with the latest games, social media and other apps. Now, these same consumers are bringing their insatiable thirst for mobile apps into the workplace.

Companies are responding to the disruption with their own take on the Apple innovation that changed the mobile world as we know it: Giants such as Pepsi are erecting their own internal app stores to quench employees’ desire for mobile business apps in a sane, safe and secure fashion. They’re intent on stopping the trend of employees and business units adopting whatever apps they want from wherever they want them, without IT supervision. In a recent IDC white paper, sponsored by CA Technologies, the research firm found that adoption of of public cloud, social and mobile technologies in business operations “has already reached high levels, often driven by “stealth IT” (i.e., by business units or individuals without corporate IT’s knowledge or support).”

Managed Security, Provisioning, Usage

The enterprise app store is a centrally managed repository of software that’s either been custom-developed, bought from a third party, or acquired under a volume license agreement through a commercial app store such as Apple’s. From this central repository, the enterprise can not only adopt the apps it wants, but it can also blacklist those it doesn’t. And, the enterprise can define who gets access to what. Based on those rules, IT can implement app security policies and automatically provision and deprovision apps as employees join and leave the company, thus preventing a former worker from accessing proprietary corporate information.

Many of these new app security tools will let the enterprise track application usage and performance, too. Software version management is another important feature, ensuring that employees use the latest approved version on their mobile devices. And, from the store repository, IT also can manage software licenses, renewals and compliance with vendor agreements.

A growing number of vendors offer enterprise app stores as part of their mobile device management and application development platforms.

And here’s where the enterprise architect can get in front of the mobile app trend and play a key leadership role: The architect can help identify the solution that’s best for his or her company and that works well within the existing enterprise architecture. Mobile app stores can be implemented as software that resides inside the firewall, as a service within a cloud architecture, or as a subscription-based service offered by carriers such as Verizon and AT&T.

If you’re an enterprise architect at an organization that’s moving aggressively toward Software as a Service (SaaS), the cloud approach is best. (By the way, have a look at this article to learn more about the trend to “everything as a service,” or XaaS, changes the IT management landscape in a big way.) If you serve in an enterprise architect’s role at a bank, where there’s hyperconcern about security and data protection, an internal software implementation is the way to go.

The Enterprise Architect Behind the App Store Scene

Enterprise app stores address the following areas of app security, and as part of the job of recommending the appropriate framework, the EA should assess how well various offerings address each piece:

• App quality — includes preventing the distribution of malware via mobile apps
• Information access — includes determining who has access to data from mobile apps
• App distribution — involves how to get apps on devices and control employee access rights
• Information at rest — affects how to determine which data should reside on the mobile device
• Data wipe — deals with removing data from mobile devices if it’s not needed or poses a security risk

In addition to identifying the best app store solution for his or her company, the enterprise architect should outline some best practices and standards that apply consistently across all the apps that will reside in the app store. For example, will the app store group applications around enterprise function, such as ERP or CRM? Or does it make more sense to organize apps by department, geography or job function? Either approach helps with the information-access issue, of course.

It’s important for the architect to be proactive and establish a common “world view” of mobile app security and management for the company, which includes getting key stakeholders on board early in the process. So, how’s your mobile app store coming along? Or are you exploring other innovative ways to secure mobile app and information access? Let us know below.

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.

Did you hear the one about the clinical psychologist who became an enterprise architect? No? Well, if this were a joke, the punchline might be that the poor guy’s spending more time in therapy now than ever before. Only this time he’s on the other end of the couch, trying to work through the pain of resistance and rejection by senior business people who tell him that they understand architecture matters but they just don’t have time for it.

As it happens, MIT’s  Jeanne Ross, one of the premier researchers in the field of enterprise architecture and IT, actually did once meet an architect who started out as a clinical psychologist — and he told her that his earlier training really helped him in his current role. Point being that much of what an EA does is as much the art of persuasion as the science of integrating data and processes, as much about gaining insight into people’s hot buttons as it is about bringing standardization into the organization.

As Ross, Director and Principal Research Scientist at the Center for Information Systems Research, explains, they have to “know how to get buy-in for something people don’t think they have time for and think that you [the enterprise architect] will take care of for them.” The problem with that is that while architects can do a lot, they can’t have a positive impact all by themselves. Says Ross, “I would urge architects to recognize that their success totally depends on other people’s behaviors, and thus they can never give up working on other people’s behaviors.” (Are you seeing the psychology connection now?)

Ross, who gave a keynote presentation on how enterprise architects can design business success at The Open Group Conference in San Francisco in January, says that architects don’t always recognize that not everyone necessarily gets what it means to have enterprise processes and what it takes to get enterprise data. That’s not to say that their business peers aren’t logical and smart people, but, Ross says, “they’re thinking in silos and silo-thinking works against all that architecture tries to do.”

To counter this, Ross says you need to be prepared to go against some natural inclinations of what you think you should be spending all your time doing — focusing on design — and what you actually should be spending time doing. The great architects, she says, are in the field, spending time with the people designing processes, for instance, or heading up call centers. They’re stepping back from the big-picture view of creating enterprise value and instead first asking themselves who it is in the organization that is best positioned to make things happen — “Who wants something in the worst way that will be better accomplished if it’s well-architected,” she says. So, your plan should be to get them to recognize that the best way forward is to think end-to-end, about integrated processes or shared data. “Invariably there’s some piece that some people will get,” she says. And those movers and shakers become your champions. 

Being proactive with the business side also means that chief architects likely will find themselves in the position of constantly forcing more clarity around the operational decisions of senior executives that, frankly, in many cases aren’t very clear. Their desire to take steps to transform the business, which includes transforming the architecture, is real but doesn’t always take into account long-term impact and the metrics that will be used to gauge it. “Architecture comes down fundamentally to two things: standardization and integration. Many senior executives think about neither in the long term, and because they don’t think of it, in a way architecture is impossible,” Ross says. “If a company has made no decision on what to integrate and standardize, you can’t go forward.”

The job, then, is to make it plain that integration and standardization will be in vain unless the business understands the real commitment this entails, and the impact that it will have on the company in terms of what it can and can’t do going forward. “A lot of companies haven’t gone the step beyond to talk about how we operate, how people’s jobs would change, about how their relationships with customers would change,” she explains. “Architects have to articulate that if I do this, then that is the result. You can help them understand the implications of their decisions.”

In other words, you have more leverage than you may think. Ross says that in her experience working with companies that have succeeded in IT-enabled transformation initiatives, the CIOs had good architects working with them. As one example, the Commonwealth Bank of Australia began a transformation in 2006 focused on meeting its customers’ need to be treated as one entity across all the divisions they dealt with. The inclination of many architects, she says, would have been to do a major overhaul, consisting of ripping out the legacy system and putting in a new banking engine, but here they focused on getting to the big impact through smaller initiatives with more immediate results. The bank began with doing just enough of an architecture revision on the back end to deliver a friendlier Internet interface to the customer. “They said, let’s fix just what we need to fix [to create] a single interface for the customer so it looks better in the back end than it is. That is brilliant,” she says. A few years later, having met their desired operational metrics — operational costs as a percentage of revenue and customer satisfaction — they’re ready to take on the banking engine itself.

Bottom line: “In companies where leaders have religion about architecture, it has a huge impact, and individual architects have a huge impact,” says Ross.

To be successful at proselytizing requires knowing your audience well, of course. To gain that insight, perhaps it wouldn’t be a bad idea to sign up for a Psych 101 refresher online, or reflecting on a couch before diving into the EA challenge.

Is the term “enterprise architecture” echoing through the halls of U.S. state and local governments? Not quite, but that doesn’t mean that the practice is not having a quiet and compelling influence — and maybe a growing one, as well. Fiscal pressures are leading some state CIOs to think that their clout may increase if they can help see their governments through these tumultuous times and create more of a “state enterprise” across agency silos.

That’s my takeaway from a recent conversation I had with Doug Robinson, Executive Director at the National Association of State Chief Information Officers (NASCIO), and Eric Sweden, the nonprofit’s program director for Enterprise Architecture and Governance. While enterprise architecture (EA) maturity varies state by state, the discipline itself has become integral to meeting state CIOs’ top priorities. As a result, EA is being integrated into plans to accomplish these public sector goals. According to recent data from NASCIO, those priorities include consolidation and optimization, budget and cost control, governance, the cloud, shared services, and security. (As you can see from this 2008 interview with John Gillispie, former CIO for the State of Iowa, consolidation has never been far from state CIOs’ minds.) The way I read that, pretty much all are closely linked with fiscal dynamics.

Optimize and Harmonize

Let’s start with one example of how EA can pack a punch: “States that are trying to get a handle on their budgets to be more efficient will use EA approaches to optimize and harmonize,” explains Sweden. “They may not even call it EA, but they are going through the process of EA.” After all, while doing straight-line, across-the-board percentage cuts to IT services may have the virtue of simplicity, isn’t it wiser to understand what programs and activities are and aren’t delivering what’s needed — and then work a strategy out from there?

“Where you cut and what is the rationale” is particularly relevant to the current budget crisis, he says. “Maybe you should be investing in some areas and completely eliminating others; and the disciplined thinking of EA is helping with that,” Sweden says. EA’s strength is that it relates to the big ideas of managing complexity and understanding the impact of change. “Enterprise architecture drives people to think through processes, the organization and information, and [we hope, to] apply some wisdom to decision making. We don’t care about EA and project management for its own sake, but for its outcome, which is better services to citizens, more effectiveness and efficiencies, and removing redundancies to optimize the enterprise.”

Another example of EA’s impact on state CIO priorities: Before moving services to the cloud, you’ve got to understand which services are good candidates for the transition. EA provides the foundations for assessing how close a match a cloud provider’s database and data architecture are to your own, for example, or how you would go about switching relationships in the future. How about one more impact for good measure? If state and local governments are to transform by way of shared services, it’s likely that services-oriented architectures (SOA), and their reusable components approach, will play a role in that metamorphosis.

“Enterprise architecture is embedded in the decision making on all these priorities,” says Robinson.” It’s going to be the foundation.”

Overcoming Obstacles

This is not to imply that there aren’t challenges to implementing enterprise architecture practices and principles. Among the challenges: The discipline may not always be represented in overall advisory councils or governance structures; the generally higher CIO turnover at the state level means that leadership perspectives and visions may change more than they do in the private sphere; and funding decisions at the federal level may limit what CIOs and enterprise architects can do.

But, perhaps there is a greenfield opportunity in some challenges, too, such as the growth of social media usage by state officials and what that means in terms of creating architectural policy frameworks for acceptable use, accountability, retention and transparency — all very critical requirements in the public sector. There are security issues, too, and NASCIO has just issued a core services taxonomy for state IT security programs that could help states create more powerful security architectures. “From the birth certificate on, there is a tremendous amount of personal information” available, says Robinson. It’s important, therefore, to protect it from both the infrastructure side and the policy, audit and compliance side, he says.

Here’s a question for enterprise architects (whether you go by that title or not) on Smart Enterprise Exchange and Smart Architect who work in state or local governments around the globe: How do you see your discipline being leveraged to support priorities, and what more would you like to see?

What’s the future of enterprise architecture management? Detecon Consulting, an information and communications management consultancy headquartered in Bonn, Germany, expects to soon publish new research that explores this topic from the perspective both of businesses and the vendors that supply them with enterprise architecture (EA) tools. With some exceptions, both parties are predicting the same outcome: While EA is currently viewed in many organizations in terms of technology-operational or technology-strategic issues, that isn’t a sustainable model. Enterprise architecture’s future is to manage the whole enterprise, not just IT.

“What I have seen, not only in our study but in discussions with other customers and industry partners,” is the need for a “strategy to expand and extend their function into the business,” says Marcel Berneaud, Managing Consultant, Team Head EA Transformation, at Detecon. This expanded concept of EA is playing out in the implementation of roles such as demand manager or business architect, for example, to create better alignment between the business and IT. “The demand from the business side is that EA management should help them in a more business-strategic way, not just in a technical way.”

Phasing-in the Changes

But many wonder whether senior executives will embrace a broadened view of EA possibilities that will make it possible for architects to deliver strategic business management, and where might they draw some lines. For instance, many organizations need to encourage more skills development so the staff can apply EA frameworks to managing the extended enterprise rather than just the information systems. And perhaps there’s a need for bigger budgets to develop these skills, too, leading to some fears that a holistic approach of EA management might be too grand a scheme. The good news, says Berneaud, is that it is possible to take a phased and sequential approach to moving EA beyond its IT borders.

Starting sooner rather than later makes sense when you consider trends and challenges such as globalized businesses that require the enterprise to act in totally new environments. When you think about the international environment, “with many suppliers and customers, you need to see the big picture,” explains Detecon consultant Aneta Nowobilska. “You need new methods that let you handle your processes, enable the integration and exchange of data. Enterprise architecture can support these scenarios.” 

The Trends for Enterprise Architecture Management and Tools study explores many other scenarios, too, although the study also cautions that disparate viewpoints need to mesh a little better when it comes to whether or how EA tools can support the extended view of the function. The Detecon team points to some vendors having more of a technical history and maintaining their focus on the IT part of EA management, while others are trying to push the envelope even when architects themselves aren’t sure of how deep to go. For example, they’ve seen that EA tool vendors are finding it important to consider business continuity because it plays into the bigger picture of corporate risk management. But the research shows that some companies don’t see EA methods as having a role in supporting business continuity. Conversely, EA stakeholders are thinking more about their role in the mobile device/universally available information world, whereas some tools vendors haven’t seen mobile support as part of their job. 

New Vision of EA

Detecon is hopeful that its study will accomplish a couple of things: On the one hand, it can give enterprise architects more proof for persuading management to embrace EA for business requirements without fear. That can be found in advice on choosing pilot projects and applying EA management methods to show how well they can support business strategy and contribute to IT and business alignment. For their part, tool vendors will get some insight into what their customers are thinking that could play a role in how they evolve their tools. “It’s [about] what companies want to do in the future with EA management. And, if they want to stay competitive, they’ll have to comply with that vision,” says Nowobilska.

When it comes to EA's role in managing the enterprise, you can see that we at Smart Architect couldn't agree more -- just have a look here, or here, or here, for starters, Feel free to weigh in with your own thoughts on EA's impact on strategic business management. 

As an enterprise architect, I sometimes say things like, "my gut says," or, "I feel this is right." It's precisely this touchy-feely approach to architecture that can get even the best in this business into trouble. So, when my stomach says to go right ahead with something, I force myself to pause and look for real data to back up the idea.

In the end, after all, it's better to say of an architecture effort that, "We made an informed decision."

Getting to that point often requires using business intelligence (BI) tools and other investigative approaches to suss out support for your ideas, innovations and key decisions. You might think OLAP (Online Analytical Processing), data mining and other reporting is out of scope for the architect (You have, of course, seen it applied successfully by IT for business requirements, in cases such as CVS Caremark Corp.'s culling of predictive customer loyalty data to recommend products to customers, or Hallmark Cards’ use of BI systems to identify which customer groups are best approached via direct mail and which are more effectively contacted via e-mail.) But let's review the definition of BI. Forrester Research defines it as "a set of methodologies, processes, architectures and technologies that transform raw data into meaningful and useful information used to enable more effective strategic, tactical and operational insights and decision making."

Good BI tools, when combined with your corporation’s enterprise metrics and your own measurements, can help serve as your decision-support system. Utilizing all these elements directly affects your requirements-gathering operation for new applications and your plans for enhancements to existing applications; decisions about infrastructure upgrades for performance and efficiency; and conclusions about driving cost-savings across your organizations’ IT systems. And more.

BI Methodology for Enterprise Architecture

Keep in mind that, as with architecture itself, there are two levels of BI: micro and macro. At the micro level, we mine data and apply it to individual applications and user needs. At the macro level, we apply the data to the entire organization’s business strategy and overall IT architecture.

Both levels are explored in the following proposed methods for applying BI:

• Knowledge gathering: Mine your application and user data for usage patterns, security issues, deployment issues, defects, administrative statistics, data usage and feature usage.
• General analysis: Apply formal math for statistical analysis and modeling, in order to uncover hidden relationships that can improve applications.
• Measurement: State key areas, unique to your organization, that need to be consistently measured to gauge architecture success, such as raw performance numbers, user sessions, downloads and so on. Using this data at both micro and macro levels will help uncover architecture issues, and lead to better decisions going forward.
• Collaboration: Build a platform for collaboration that uses the data and measurements you derive from your BI efforts, and share it across the organization and with other organizations. This may require the use of XML, EDI or other standard protocols.
• Reporting: Just as the enterprise is required to produce annual reports and other financial reports, so should the EA produce statistical application reports related to architecture. The output should serve to feed the business strategy of your enterprise as a whole, along with its entire IT strategy, and the design and architecture of individual enterprise applications.

Many of the steps in this methodology involve data and interfaces with the applications themselves. But there’s more to it than that. For instance, the EA needs to be involved with user information-gathering through questionnaires and interviews, as well as in engaging with administrative staff for direct feedback. Time-reporting tools enter the picture so you can see which areas of software development have required the greatest investment.

Remember, as an enterprise architect, you can leverage off-the-shelf BI packages to help the entire process instead of building it all yourself. Tools are available to help with all areas of business reporting and application monitoring. CA Clarity PPM, for example, provides a suite of tools that promise to improve your project success rate, and help you more quickly solve business problems.

Look for the following key capabilities in any solutions you choose:

• Financial management: The ability to gather and measure transaction data and project revenue, project costs and growth analysis;
• Project management: The ability to track actual resource usage and hours against projections, which help you to be more accurate in future development;
• Reporting and documentation: The ability to get results tailored to fit all stakeholders: C-level executive decision makers; enterprise architects and other architects; project leaders; and the developers themselves.

Dive Deeper Into BI's Value

BI is about formal measurement and analytics, which lead to informed decision-making in terms of business problems and the solutions to them. If you need to be further convinced of the value of BI, look at how enterprises are using portlet-based architectures to quickly assemble composite applications; data visualization to uncover the hidden value in existing data; business process management for automation and cost savings; and new collaboration tools to increase efficiency.

As an example, let’s look at what experts are calling location intelligence: The ability to collect pertinent data based on a mobile sales force’s location can create a feedback loop of information that, once analyzed, can lead to decisions that make the team more efficient, and potentially give the business a competitive edge. 

For more examples on how BI is helping enterprises in new ways, check out the following:

• Moving BI to the Enterprise 
• 10 Hot BI Trends 
• Location Intelligence: Now SaaSier than Ever 
• Agile BI: Power to the People 

Whether you're supporting the business in making a business decision that will drive your architecture, or you want to double-check your gut instincts for any architectural decision, look to employ BI tools and methods to meet your needs. We’d like to know how you see BI tools fitting into your role as enterprise architect, and we’re sure your peers would like to know, as well. Feel free to share your experiences below.

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.”