The Ponemon Institute recently completed two interesting studies on IT security. In the first, its annual “U.S. Cost of a Data Breach,” the research firm focused on privacy, data protection and information security policy and found that the cost of data breaches in the U.S. is rising. According to the report, the average cost in 2010 hit $214 per compromised record. That's markedly higher when compared to 2009, when the figure was $204.

The costs associated with data breaches include those related to notifying customers, legal fees, investigations and lost business from what Ponemon categorizes as abnormal customer churn. And it appears that enterprises that respond quickest to the breach actually end up spending more than those that are more deliberate in their response. That's because in the rush to get the alerts out (as required by many breach-notification laws), companies overnotify parties, the report says, and this little contribution they make to damaging their own reputations actually increases customer losses.

The second Ponemon survey, of more than 2,400 IT security administrators from around the world, found security complexity is the No. 1 challenge faced by organizations. Undertaken in conjunction with vendor Check Point Software Technologies, this report, entitled “Understanding Security Complexity in 21^st Century IT Environments,” (a release about it is here), found that more than 55 percent of companies now are using more than seven security vendors.

And, as cloud computing, mobility and the consumerization of enterprise devices increase, the complexity associated with securing systems and data will, too.

What can an enterprise architect do about all of this? Plenty.

First, (as we noted in my previous post), a security architecture that is aligned with the business requires an adept enterprise architect who early on helps integrate security into the design and requirements phases of a deployment. Efforts here will help reduce the costs and complexity of IT security overall, because it is much less expensive and difficult to build systems that are secure from the start than it is to bolt security on later, and because it makes for a much more resilient infrastructure.

Second, enterprise architects know where the regulated data is stored, where it's processed, and how it's transferred and shared across systems. So they can reduce the complexity of dealing with information that falls under the scope of regulatory compliance mandates by fostering solutions that limit the sprawl of personally identifiable and other forms of regulated data. Their work may not only help limit the number of systems that could possibly fall victim to a reportable attack, but may simplify defenses, too.

And, should a breach occur, those efforts will make it easier to rectify and remediate. And, as is pointed to by the Ponemon study, that’s work that directly correlates to the costs of a breach, so anything that smoothes those processes is a win. For instance, the time spent during the forensics investigation will be reduced because the affected systems will be known right away. Also, the impact of that breach will likely be lessoned because security controls – adequate segmentation, encryption, access controls -- will have been built as part of the system.

They are just a couple ways the enterprise architect can help simply security and reduce the cost of data breaches. What strategies do you employ to streamline the security efforts at your enterprise?

In response to Jennifer Zaino's posting, I have been in an architecture role for a number of years.  The best explanation I have to describe the type of work we do is "changing a culture".  Most of us in architecture understand the fundamentals of systems, processes, and (this may be a stretch) services; at least conceptually.   We'v e been to conferences and classes on the technical aspects of Enterprise Architecture, and can espouse the virtues and steps required to achieve it.  Where we prove our worth and show our value is understanding the behavioral changes that must take place in order to align with the processes required to manage those systems and processes and working with senior managers to come up with a plan to address them.  In my experience, most of the time, these types of "cultural changes"  are dependent on the current maturity level of those processes and systems in terms of their ability to perform or be accountable as a service of IT to the business. 

Even if IT "gets it right", the business must also be willing and able to dedicate the time and resources required to manage the business and IT to a different level of transparency and accountability that is based on real metrics mapped to process level metrics that are tied to real dollars.

This is why I believe it is truly a "culture change".  All the people in the organization must "get on the same page" and work together to ensure we don't allow existing or old behavior to be applied to new issues and initiatives.  Until the rewards for new behavior catch up to the expectations of enterprise architecture, it is difficult for the architect (enterprise or otherwise) not to come across as the "sounding brass or clanging cymbal".

As Jennifer mentioned, this plays to the personality of the Enterprise Architect.  The successful enterprise architect will be the one that can recognize not just the current and future state of the systems and processes within their organization, but the "next state" for each of the process areas within the adopted management framework.  Once this is understood, and a plan in place to move to that next level,  the gratification of knowing comes from knowing the "next state" is in progress and leading to the future state and vision while recognizing the future state is constantly evolving.

My two cents,

I’d like to give a shout-out to my son’s second-grade teacher this week, for posting this quote on the class page on the school’s website:

“In teaching you cannot see the fruit of a day's work. It is invisible and remains so, maybe for twenty years."
- Jacques Barzun

I found it interesting that this should come to my attention just now, as I’d recently been thinking about how enterprise architects probably spend a lot of time in a state of delayed gratification. Maybe not 20 years, but enterprise architects’ work often has more of a cumulative effect than a big-bang blast. That's unlike functions where the impact to the business is more immediate, such as when a new app developed by the software team goes live and leads to a quick rise in productivity.

That’s not to say that the final results won’t have a dramatic impact on the business, just that there are a lot of incremental steps on that road to creating a flexible infrastructure and adaptive business processes and services. And often, there are a lot of what may seem to be meandering discussions along the way.

It takes a certain outlook to gain satisfaction under these circumstances, and I’ve begun to wonder whether that’s a mentality that will be in shorter supply as we prepare the next generation of enterprise architects.

It’s not that I think today’s young adults don’t have the discipline or the talent to succeed in demanding and tech-influenced fields such as enterprise architecture. They’re probably better prepared as a result of growing up with the power of technology infusing every aspect of their lives. But they’re also very accustomed to a culture of positive reinforcement and encouraging feedback in the service of a strong self-image, which wasn’t necessarily the norm when we, um, more mature folks were growing up — at least not to the same extent. (There was a time when not everyone on the Little League team was Most Valuable Player, right?)

Perhaps it’s not enough reward to just know that their work counts toward unifying the IT environment and linking it with the business. These future enterprise architects may have to challenge themselves to find more concrete reinforcement from the fact that their work is making a tangible and ongoing difference — which isn’t necessarily a bad exercise to undertake, even for more seasoned pros who may sometimes feel a little underappreciated.

How? For starters, how about sharing in those software-development triumphs? For example, consider how laboring over an enterprise architecture repository means that it takes your company 10 percent less time to bring a new app to market — a time that will accelerate as the repository is enriched.

Or how about every time you read about another devastating data breach, you do a high-five for the data architecture governance steps taken to ensure appropriate access to information and its security, too (and then just go back and double-check things, lest you tempt the fates).

I won’t pretend I’ve got a full suite of answers here, but I would love to know what your thoughts are about the little reward moments that enterprise architects should take time to appreciate. What keeps you going, and what would you advise those younger architects to think about to keep them driven toward bigger-picture goals?

Jennifer Zaino is executive editor of Smart Architect.

As a journalist specializing in IT security issues, I regularly talk to a lot of CISOs as well as the security folks working in the trenches. And there’s one thing that never ceases to amaze me about so many of these conversations: After all these years – and all the hacks and attacks we’ve seen take place over them -- security teams generally still run a step or two behind the deployment of new IT initiatives.

That places security groups in the unfortunate position of having to "bolt on" security controls well after a new project is under way. And that hard to do; it's tough to add security after a system has been designed or once a deployment gets going, whether that is the launch of a website or Web application, a system integration, or a move to a cloud service.

How is it that this continues to be the normal state of doing business – especially when the risks enterprises face aren’t exactly letting up? If anything, the danger is taking on new and potentially even more lethal forms when it comes to infiltrating business’ most privileged information. Consider some recent high-profile attacks, such as Operation Aurora, that targeted Fortune 500 companies, including many Western businesses — Google among them. Then there were the Night Dragon attacks, revealed in February, that were aimed at some in the energy industry. Most of these attacks are considered to be cyber-espionage. It’s widely assumed that they are the work of highly skilled and determined hackers on the payroll of nation-states and possibly even foreign business interests that want to steal corporate secrets.

Lately, we’ve also seen a spate of so-called cyber-hacktivist attacks, where businesses perceived to be taking a stand against Wikileaks were hit with embarrassing hacks and denials of service.

Pointing to those headline-making events doesn’t mean that less spectacular and less-publicized attacks that are perpetrated for common, everyday data and identity theft are any less important. They're not. Businesses daily confront online criminals with such evil intents in mind. Obviously, IT security organizations pay great attention to news of all kinds of security infiltrations, and clearly they have good intentions of making sure their business is not the next victim on the hit-list. But it’s hard for them to live up to those intentions when they’re not consulted to provide their expertise as soon as new initiatives are approved.

Change The Game

There is hope that lack of communications – even if it has festered as long as this – can be rectified. And I think enterprise architects can play an important role in making that happen.

Here’s how: Enterprise architects, who have a firm understanding of how systems are being deployed as well as knowledge of the business objectives behind these systems, can help a great deal when it comes to protecting an organization's business technology systems and information. To build security into new initiatives and system changes requires tight — and upfront — coordination among many groups. The enterprise architect can drive value in aligning security teams, quality assurance personnel, developers, the office of the CIO, and business managers and executives. All those parties — and the enterprise architect, as well — must work together to ensure that the focus and resources necessary to maintain a secure IT posture are in place.

I'm certainly not claiming this is going to be easy. For one thing, communications between security leaders and enterprise architects may need some work. While CISOs claim they're too often left out of early talks about new initiatives, I’ve had conversations with a few EAs who’ve grumbled that security teams are too quick to say no to them, and that can create hard feelings. There clearly seems to be some bridge-building to do between the groups.

What has been your experience as an enterprise architect in communicating with the security team? And how do you see your role in helping to align business, technological and security demands to protect your organization? I’d appreciate hearing your story, and any ideas or experiences on the topic that you'd like to share. I also invite CISOs to join the conversation and add comments here or send me note on the Exchange.

As a journalist specializing in IT security issues, I regularly talk to a lot of CISOs as well as the security folks working in the trenches, too. And there’s one thing that never ceases to amaze me about so many of these conversations: After all these years – and all the hacks and attacks we’ve seen take place over them -- security teams generally still run a step or two behind the deployment of new IT initiatives.

That places security groups in the unfortunate position of having to "bolt on" security controls well after a new project is under way. And that hard to do; it's tough to add security after a system has been designed or once a deployment gets going, whether that is the launch of a website or Web application, a system integration, or a move to a cloud service.

How is it that this continues to be the normal state of doing business – especially when the risks enterprises face aren’t exactly letting up? If anything, the danger is taking on new and potentially even more lethal forms when it comes to infiltrating business’ most privileged information. Consider some recent high-profile attacks, such as Operation Aurora, that targeted Fortune 500 companies, including many Western businesses — Google among them. Then there were the Night Dragon attacks, revealed in February, that were aimed at some in the energy industry. Most of these attacks are considered to be cyber-espionage. It’s widely assumed that they are the work of highly skilled and determined hackers on the payroll of nation-states and possibly even foreign business interests that want to steal corporate secrets.

Lately, we’ve also seen a spate of so-called cyber-hacktivist attacks, where businesses perceived to be taking a stand against Wikileaks were hit with embarrassing hacks and denials of service.

Pointing to those headline-making events doesn’t mean that less spectacular and less-publicized attacks that are perpetrated for common, everyday data and identity theft are any less important. They're not. Businesses daily confront online criminals with such evil intents in mind. Obviously, IT security organizations pay great attention to news of all kinds of security infiltrations, and clearly they have good intentions of making sure their business is not the next victim on the hit-list. But it’s hard for them to live up to those intentions when they’re not consulted to provide their expertise as soon as new initiatives are approved.

Change The Game

There is hope that lack of communications – even if it has festered as long as this – can be rectified. And I think enterprise architects can play an important role in making that happen.

Here’s how: Enterprise architects, who have a firm understanding of how systems are being deployed as well as knowledge of the business objectives behind these systems, can help a great deal when it comes to protecting an organization's business technology systems and information. To build security into new initiatives and system changes requires tight — and upfront — coordination among many groups. The enterprise architect can drive value in aligning security teams, quality assurance personnel, developers, the office of the CIO, and business managers and executives. All those parties — and the enterprise architect, as well — must work together to ensure that the focus and resources necessary to maintain a secure IT posture are in place.

I'm certainly not claiming this is going to be easy. For one thing, communications between security leaders and enterprise architects may need some work. While CISOs claim they're too often left out of early talks about new initiatives, I’ve had conversations with a few EAs who’ve grumbled that security teams are too quick to say no to them, and that can create hard feelings. There clearly seems to be some bridge-building to do between the groups.

What has been your experience as an enterprise architect in communicating with the security team? And how do you see your role in helping to align business, technological and security demands to protect your organization? I’d appreciate hearing your story, and any ideas or experiences on the topic that you'd like to share. I also invite CISOs to join the conversation and add comments here or send me note on the Exchange.

Some years ago, I had a conversation with one of the enterprise architects at CyberCash (now part of PayPal) about what an enterprise architect does. He offered a lot of insight, but one thing he said really struck me at the time, and has stuck with me since: A truly successful architect manages software builds.

That’s right: builds — as in compiler.

Of course, there are the business modeling, systems integration, and forward-looking technology tasks too, but enterprise architects need to be involved with the end result — the bits that come out of the system(s) that compile and package the end-deliverables. In a sense, it’s like a sausage: Lots of strange things go into it, but only the results matter.

His point was, that by working with development, and tracking how the software is actually delivered, the enterprise architect is assured that the architecture will be carried through to the end. As I’ve mentioned before, working with developers creates a constant feedback loop where development is driven by architecture, and architecture is further refined by development.

But for today’s enterprise, the build and deployment systems themselves must be designed, deployed and managed, often on a continuous basis. For this reason, it’s important for the enterprise architect to be up to date on the state of continuous integration systems.

The Bus Stops Here

Before we dive deeper, I need to mention release schedules and iterative development. Gone are the days of one-year development cycles, where really large product releases were carefully planned and infrequently launched. Most organizations have adopted an iterative model, where software cycles are measured in months, and sometimes weeks.

At each company I’ve worked at or consulted with, I’ve successfully deployed what I call the “bus stop release cycle.” With this approach, releases are planned by projected date, not feature sets. Although features are targeted to a particular release, if they don’t make it in time, that’s just too bad; the software goes out the door anyway.

This is much like the way buses run (or should run!): They leave each stop at a scheduled time, regardless of whether every passenger who wanted to be on board is there or not. Whatever features are ready for release get on the bus, if you will, and are deployed. However, in some cases, this isn’t fine-grained enough.

Some enterprises go to the extreme of planning continuous builds and deployments of their software. There are many good reasons to do this, such as ongoing testing and evaluation, 24-hour global development processes, and very large-scale software development. The process includes developers around the world constantly writing code and checking it into a source code repository. Behind the scenes, this new code is pulled out, compiled, integrated with other new code and deployed to QA systems where unit and integration tests are run.

Continuous Integration

The systems and processes that enable this can become as complex as the software they're building, which motivated the definition of the continuous integration (CI) paradigm. This paradigm, used to automate and unify the software build and test processes, was made popular with Project Hudson, developed and used by Sun and subsequently released through the MIT open source license. Other solutions exist, such as #CA Plex in conjunction with CA Software Change Manager, or Electric Cloud's suite of software.

However, these continuous integration systems don't just deploy themselves. They need to be thought out, managed by IT, and migrated to the latest in hardware, compiler and test software, constantly.

Sometimes called development clouds, continuous integration systems are clearly in the domain of the enterprise architect. For instance, the following issues need to be considered:

● Hardware resources: Multiplatform builds require hardware resources to be available centrally within your data center, and not just on developers' desks.

● Virtualization: The ability to scale many-core systems into individual virtual systems, and to be reconfigured on the fly, helps enable just-in-time, large-scale integration.

● Management and reporting: Software builds need to be scheduled either by time, check-ins or manually through administration URLs. The build results then need to be logged and reported back.

● Deployment: The resulting software needs to be either automatically or manually deployed to the right servers, depending on software type.

● Administering tests: The proper test suites with optional input data are then scheduled and run against the newly built software, with results reported to the appropriate development groups.

The process of continuous integration involves work-flow management, parallel processing (different phases can run in parallel even within the same software package), databases and data feeds for input data, resource management as proper servers are located for new software, and reporting tools for the test results. It's important to automate these tasks as much as possible as you take advantage of global development teams.

Continuous integration packages also help to pinpoint weak points in your internal processes, IT systems and even technology choices, often helping to accelerate the entire process. Further, most CI packages allow for customization and extension through plug-ins, which you define and build to your organization's specific needs.

To summarize, as an enterprise architect, your main job is to define the building blocks to meet business needs, but it's important to see the development process through to ensure that your vision is implemented. Although the development and release cycles offer valuable feedback to the architecture as a whole, they shouldn't become bottlenecks. Since today's software build-and-test cycles may often be too large for one person to manage, it's important to take time to examine your company's internal IT to ensure that it can deliver these solutions as efficiently, effectively and robustly as possible.

Your architecture skills, combined with existing CI software packages, can ensure that the enterprise is on the path to efficiency with continuous software integration.