IT organizations often make difficult choices depending on business demands and budget constraints, but in the realm of software testing, the standard approach didn’t allow for much choice. Application developers, architects and even IT operations staff tasked with testing applications against real world conditions have often found themselves debating which could be sacrificed – cost, quality or schedule – when working to deliver new applications.

“Traditionally, you might have had the luxury of moving one or maybe two of the needles in the right direction, if you were really lucky, but being able to move all three just wasn’t an option,” says Burt Klein, senior customer advisor at ITKO, a CA Technologies company, and former Bank of America Performance and Resiliency Executive. “All three – speed to market, cost and quality – are critical for the process, but testing to accommodate all three just wasn’t possible.”

That is, until service virtualization technologies opened up a whole new world of options and helped testers stop undergoing a painstaking “Sophie’s Choice” of sorts with each application.

Service virtualization is a capability offered in technologies from a handful of vendors today that allows application testers to remove the constraints from their software development lifecycle. The technology lets architects virtualize an environment and the application parameters to avoid using sparse physical resources not readily available for testing purposes. The virtualized environment can more accurately emulate a production environment under different scenarios and enables application developers to better design their code as well as help architects plan for capacity. More important is service virtualization’s ability to let testers configure their virtual test environment to deliver applications at lower costs, with improved quality and at a faster time to market.

“Service virtualization is part of the larger market we define as lifecycle virtualization, and it is the element that really helps IT to manage the classic ‘cost, quality, schedule’ triangle,” says Theresa Lanowitz, industry analyst and founder of Voke Inc. “For years, applications would be delivered with at least one element off, whether it be over cost, late to market or lower quality. Service virtualization eliminates the constraints the test group has, lowers costs and helps to deliver better quality software.”

The market for service virtualization technologies is young, but heating up, according to Lanowitz, who says she has been tracking it since as early as 2005. CA Technologies acquired ITKO in the summer of 2011; then soon after HP started to renew interest in its own service virtualization product of the same name, HP Service Virtualization. IBM in January closed its acquisition of Green Hat, a provider of software quality and testing solutions for the cloud and other environments.  Now ITKO’s primary competition before the acquisition, niche player Parasoft and its Parasoft Virtualize, has to compete with three of the largest software vendors in the world.

The interest in the technology isn’t entirely surprising, and not just because some of the big players are starting to include it in their portfolios. With very public technology failures, think retailer Target’s Web site crashes and BlackBerry provider RIM’s network outages, IT leaders and application organizations are more aware than ever how poor software could impact their brand and ultimately hurt the business’ bottom line. In today’s environment, delivering low quality software could break a business, but traditional approaches to testing also require capital expenditure upfront and slow time to market.

“With so many catastrophic software failures in the last year, headlines are being written about software, CEOs are resigning, stocks are tumbling,” Lanowitz says. “People are realizing they need to manage that triangle better and deliver software with a level of risk that is palatable versus the unknown.”

Do you Tweet? Follow Denise Dubie on Twitter here.

The disruption from the iPhone and iPad continues years after Steve Jobs started the revolution in smartphone technology. Due to demand by customers, enterprises serving consumers must consider how to provide that audience mobile applications that interface with their otherwise internal enterprise systems. Some examples of this from the financial services industry include Credit Suisse’s Onyx Touch, Merrill Edge for iPad and Bank of America’s Research Library.

It’s important for the enterprise architect to understand how each outward-facing application affects the infrastructure, so that he or she can plan for the big picture dealing with design, reuse, automation, integration, security and more. To get a thorough understanding of the issues involved, I recently spoke with a developer who has built multiple consumer-facing iOS applications with enterprise access for a Wall Street financial services firm. I was surprised at what I learned that affects my own work — and you may have the same reaction.   

The first thing I learned is that perhaps we architects are too concerned about the scalability demands created by a more mobile consumer audience. The developer with whom I spoke  explained to me that if you have architected your back-end systems to scale to support consumers accessing Web apps from their PCs, those systems are ready to perform for mobile visitors, too.

It’s in the area of security that what you’ve done for your consumer-facing Web apps differs from what you’ll need to do for your consumer-facing mobile apps. (But you probably guessed that, didn’t you?)  

Insecure About Security

Let’s break the issue of security down a bit further, to examine the not-so-obvious consumer/enterprise issues, such as:  

• local storage
• encrypted communication
• session management
• remote data wipe

“The biggest concern with our mobile apps [deals with] locally stored data,” said my source. If a consumer is using a mobile app to access data that is owned by the enterprise or another entity, such as one of its partners, it’s too risky for certain businesses to provide an option [that lets] the user locally store that information or any operations he conducts with it. It opens the door to problems for the business if the consumer’s device is lost or stolen.  

“You need to view it as though you’re lending the data to look at. You need to stop common operations such as copy/paste,” according to the developer. A seemingly valid consumer user may in fact be a rogue employee trying to steal data. Or, since it is a consumer app, you may not be able to even identify the users at all.

Obviously, there are some industries and/or mobile apps where local storage isn’t necessarily a problem. There’s not much at stake, for instance, if a user can store the ranking stats for an entertainment company’s mobile multiplayer game on his iPad. Where corporate data security is a concern, could strong local encryption make a difference? Yes, and it’s an area where the enterprise architect also must help set standards. “The data accessed by mobile apps needs to have stringent security requirements, based on those from the enterprise data group,” my source said. Strong encryption is necessary when communicating over cellular or Wi-Fi networks, for starters, and even temporary files need to be encrypted to guard against accidental exposure in case the application crashes.

For consumer applications that give users optional access to privileged systems and/or data for a fee, strong session management should be on the enterprise architect’s standards list, as well. “Where I work, we need to support at least three types of time-outs,” said my source, for free and stepped-up levels of access. They are:

1. Inactivity based time-outs.

2. Time-outs that occur when the time between Web service calls is too long.

3. A maximum time limit for an open session, regardless of activity. This ensures that if an unauthorized party breaks into the system, the amount of time on the system is limited.

Should an issue arise about compromised enterprise data, the architect must ensure that there’s a way to deal with information existing in a local state on a consumer’s device at the time the security issue is detected. You have to make sure there is a facility for remotely wiping the data resident in local memory, along with the entire application, on the mobile device, while leaving all else on the device intact.

Another difference for enterprise architects to consider, which lies outside the security realm, is providing as much functionality as possible offline. “You should minimize features that work only when the device is connected [to the Internet],” the developer told me. The result is that users can get to features right away, without having to wait for a mobile device to boot and a network connection to be established. That’s one reason, he says, that his firm’s iPad app was preferred to competitors. (You also should read our recent feature, How to Architect a Successful Mobile Strategy for additional information on security and other requirements for mobile apps.)

In many ways, the instant-on, instant gratification offered by mobile applications at our fingertips (like the one you can read about here) lends itself perfectly to a world that demands access to critical data as quickly as possible. The real question is: What took us so long to realize this? Let us know how you’re driving a successful consumer-focused mobile strategy at your enterprise.

Analogies abound in software architecture and development. From bricklaying to skyscraper construction, I think I’ve heard them all. Frankly, they can get a little tired. That said, there are two analogies that come from the automotive industry that I reference on a daily basis: road maps and dashboards. While road maps are often associated with software release plans, and dashboards with software administration, both have helped me in my architecture work.

In my experience, most enterprise architects don’t follow a well-defined process, don’t always produce the proper artifacts, and don’t follow their projects through to customer delivery. On the one hand, this is understandable, as tracking all the existing development while planning for future business and technology needs is overwhelming. However, it’s possible to track them at least to some degree, and this is where the proper use of road mapping (to ensure a proper project progression) and dashboards (to maintain a 30,000-foot view of all development) have been proven to help.

Road Maps: The Enterprise Architect’s Guide to the Galaxy

If hitchhikers can have a guide to the galaxy, why not enterprise architects? Wikipedia describes a technology road map as a plan that matches short- and long-term goals with technology solutions to meet those goals. A good road map helps teams to agree on a direction, predict future outcomes and coordinate all processes involved.

The road-mapping process I’ve found useful includes the following phases (see Figure 1 below):

1. Planning
2. Design
3. Development
4. Debriefing

In the planning phase, the business team and the architects define the conditions for the project (i.e., customer needs, revenue goals, time frames and so on), determine who will fund and who will lead the effort, and finally, define the scope of the project. In terms of scope, it’s often just as important to define what not to do in the project. For example, definitions can mandate that you’ll adhere to the 80/20 rule to ensure budgets aren’t blown, that you will support just one mobile platform rather than use a framework that works across all of them, or that you’ll dedicate only a subset of your team for a limited amount of time for a pilot program. Overall, this phase defines the vision for the development effort.

In the design phase, the EA takes the lead and matches the business goals with technology choices, using the artifacts from the planning phase. This includes analyzing existing systems, products and development teams, and determining future needs (i.e., hiring new talent). The important artifact from this phase is an architectural road-map report that outlines the technology choices made, maps those choices back to decisions from the planning phase, provides alternative choices and takes problems into account along the way (a.k.a. Plan B).

The development and debriefing phases might seem like a post architecture activity, but as I’ve stressed in past blogs, such as this one and this one, the enterprise architect must be involved here as well. This involves continuous tracking of the product development back to the previous two phases, making alternative decisions (according to the road map) where needed, and executing on Plan B as a contingency. Debriefing generally occurs once development is wrapped up, and involves measuring the end result against the original vision, and using those results to refine the process for future development efforts.

Figure 1 - Road mapping for the enterprise architect. Illo credit: Eric Bruno

The Dashboard

A road map is useless, however, unless you know where you are, and where you’re headed. When kept up to date, a project dashboard helps the enterprise architect track a project instantly. Products such as CA's Clarity PPM help you build road maps to track and manage an entire project's lifecycle, and also include project views akin to dashboards.

In a large organization with multiple ongoing projects, dashboards are an invaluable tool, and help track the following:

For the overall business:

• Determine business needs:
• Overall health
• Growth areas (expanding existing business)
• Greenfield (new areas of business)
• Track ongoing projects
• Track R&D

For individual projects:

• Track customer requests
• Optimize architecture
• Track bugs and defects

Below is a sample mockup dashboard I created:

Some tips as you create your own are to:

• Keep it all on one slide;
• Include green/yellow/red status indicators for major areas (usually business, tech, and operations). Although there are only three colors here, the truth is this usually expands to multiple colors to account for all major areas;
• Include a summary Gantt chart of up-to-date critical scheduling, customer requests, and bugs, updated weekly (the one in the sample above is from Wikipedia);
• Include an overview architecture diagram so that you can see the data sets, major systems, and client impact all in one view.

As you can see, the dashboards get quite sophisticated even at one page, and are extremely useful when you're tracking lots of systems. Any more than one page and it's overwhelming when multiplied by the number of active projects the EA is or was part of.

It’s no accident that the elements tracked in the dashboards map back to the software road-mapping phases outlined above. I’ve found that using both tools together helps the enterprise architect maintain the unique position of understanding both the business and technology factors for problem-solving in the enterprise.  What dashboards and road maps are you using? 

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.

Have you been paying attention to how the mainframe’s role will evolve as your enterprise architecture strategy matures? You should be, considering that these systems continue to make up a significant part of business infrastructure. In several recent independent studies on behalf of CA Technologies, a significant majority of senior-level mainframe decision-makers (between 80 and 88 percent) responded that they believe mainframe applications remain a key business asset. 

My advice is that enterprise architects should be thinking of how to help their companies leverage these data center assets as viable candidates for private cloud-based transaction processing. Modern mainframes fit the bill because they are all about redundant internal components, high-speed and high-bandwidth I/O, flexibility to run both modern and legacy software, high security and extreme reliability. And, as Guillermo Merino notes in Saluting the Mainframe, only Google’s massive server farm comes close to rivaling the mainframe’s transaction-processing scale. 

How to allow mainframe workload processing to continue into the 21st century world of private clouds while reducing cost and complexity? The workflow-centric approach integrates well into modern SOA (service-oriented architecture)-based solutions.

The “Big” Event

An efficient way to integrate classic mainframe processing into a modern private cloud-based SOA is through event processing, where events can be used as inputs and outputs to workloads executed on the mainframe. For example, your Java EE software can trigger the batch processing of perhaps hundreds of thousands of transactions on the mainframe, where the results are delivered in real time, and perhaps stored in a database management system (DBMS) or NoSQL database. Thanks to these triggers, the entire system can remain technology agnostic, with no need to be concerned that it’s a mainframe providing the high transaction-per-second (TPS) processing rate behind the scenes. This is particularly important because it allows enterprise architects to strategize around the mainframe even as COBOL and JCL development skills are on the decline. Many CIOs are concerned about the looming mainframe skills shortage, as older workers with these talents retire and the younger generation isn’t equipping itself to replace them (see this article).

In Figure 1, you can see how triggers throughout the system become events that can be processed anywhere in the data center, including on its resident mainframes. On the left are event sources, processed on the appropriate systems (a DBMS, Java EE servers, mobile devices and so on), with the mainframe on the right as a potential producer and consumer of these messages. As daunting as all this may seem, it’s made quite simple, thanks to the level of abstraction the events supply, combined with packages such as CA Workload Automation ESP software.  

Automating processing in this way makes it possible to plug the TPS power of a mainframe into existing systems without concern for the vast differences in technologies. Additionally, things can run in reverse – that is, SNMP or other events from the mainframe can be processed by other components of the architecture. This dynamic workload processing allows enterprise architects to craft their mainframe strategies to efficiently meet the high Service Level Agreement demands that only mainframes can provide, all from the modern platforms and languages that developers are comfortable with.

Integrating existing mainframe software and capabilities with modern software environments through the dynamic workload processing, software from CA Technologies allows enterprise architects to guide developers in finding the “sweet spot” between the processing options.

For more on how enterprise architects and CIOs are getting the message about how to get even greater value from their mainframe environments, read this piece by Tam Harbert and her update here.. And let us know how you envision the mainframe’s place in your own enterprise architecture strategy.

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? 

Enterprise architecture is getting greater recognition in the academic realm, which clearly is a testament to its growing importance to the enterprise.

This fall, Kent State University kicked off a new master’s degree program for enterprise architecture (EA) — a program the university says is the first in the nation. The EA program is one of five concentrations in the university’s new Master of Digital Sciences degree; the university has already been offering EA courses as part of an undergraduate program as part of its School of Digital Sciences.

“Enterprise architecture is becoming increasingly important to both the IT and business side of an organization, but is not yet a common area of study in academic programs. Our Master of Digital Science degree was designed as a professional master's program to complement an undergraduate degree by adding depth in one or two additional areas — essentially a technical alternative to an MBA,” says Robert Walker, Director of the School of Digital Sciences at Kent State. “For a graduate in an IT area such as computer science or computer information systems, adding expertise in enterprise architecture is a great way to open the door to new career options.”

A gift from the Enterprise Architecture Center of Excellence (EACOE) to Kent State University’s new School of Digital Sciences is funding the courses at both the undergraduate and graduate levels. The EACOE is a practitioner-based association for the EA profession and is focused on establishing professional standards, conducting research, providing information, and promoting professional and career development. The association offers practice-based certification, professional networking and knowledge-development opportunities. The EACOE is donating to Kent State a five-year license to use its courseware in the School of Digital Sciences’ curriculum, a gift valued at $3.2 million.

Kent State’s new master’s program is designed for working professionals or new graduates who have a degree in a related area, and who want to round out their technical knowledge with topics outside of their degree area. The master’s program launched in August, and 15 students are currently enrolled.

Denise Bedford, who is currently the Goodyear Professor of Knowledge Management at the College of Communication and Information at Kent State and also a certified enterprise architect, says that while there are a number of good training programs available to professionals, most are just five-day courses. “If a company wants to have people who are really well-trained and thoroughly trained in enterprise architecture, it takes more than five days.” Bedford serves as a faculty member in the School of Digital Sciences. (In our feature, Agile Business Begins with a Formal EA Program, Bedford and other experts will discuss how businesses can support technology, organizational and business goals by formalizing internal enterprise architecture efforts.)

The EA concentration at the graduate level consists of five courses, including an introduction to EA. A course description for that reads:

Facilitates the alignment of IT and IS (information systems) investment decisions with business goals. Enterprise architecture is increasingly used in industry as a result of the continued emergence of new technologies and ongoing pressures to re-engineer business processes to achieve improved efficiency and greater customer focus. Enterprise architecture identifies the main components of an organization and the ways in which these components work together. The components include performance and strategy, people, business capabilities, applications, technology, knowledge and information, as well as financial and other resources. 

The university also will offer courses on business architecture, management of Enterprise Architecture, data architecture and application architecture. To earn a Master of Digital Sciences degree with a concentration in EA, students must successfully complete 32 credit hours of graduate courses. In addition, Kent State’s graduate EA program is being delivered online.