Skip navigation
CA, Inc.
TwitterLinkedInShare Smart Enterprise
Home Business Technology Innovation Business Technology Strategy Business Technology Execution Professional Development Smart Groups Smart Enterprise Magazine

Smart Architect

11 Posts tagged with the security tag


This year’s Smart Architect session, held every year at CA World, took practical collaboration to a whole new level. Smart Architect brings our clients’ top technology architects and CTOs together with CA Technologies top engineering talent in a closed door, invitation-only, intimate discussion of all that is happening with technology. It’s one of the hottest tickets at CA World.

Smart Architect provides this select group of lead architects with insight into the CA Technologies roadmap, and they, in turn, give us feedback on how they are using technology in their own organizations. The discussion is about advanced technology, but always grounded in practical results.


This year we did something new that I think worked especially well: Each session was developed collaboratively by a CA technologist and a client executive. The two would jointly present a user story, looking at the technology problem, the challenge to the industry, and the solution. Then they would discuss how we worked together to overcome the problem, specifically focusing on how the organizations, themselves, measured the success. This approach gave other attendees in the room a very balanced view of the technical concept and its outcome.


Talking to a lot of the technology executives who attended, most told me they found the greatest value in hearing from their peers on exactly how challenges were overcome and how they went about solving them. Half the time, the important thing wasn’t even the actual solution. They loved collaborating with their peers and having the opportunity to ask questions like:


“How did you identify this problem?”

“How did you gain support?”

“How did you build that business case?”

“How did you overcome the naysayers?”

“What other alternatives did you look at?”

“Why did you select that?”


There were also some really great technical discussions, such as the one on whether a company should federate its logins with visitors’ social media identities. Outside of the financial area, a lot of companies are very willing to simply lock in or federate accounts with their Facebook or other social media identities. The discussions showed that we had a great diversity in the attendees. We certainly had a strong representation of financial services, who remained skeptical of federating logins. We also had a lot of retailers and people from consumer products companies as well, and they were more open to federating identities.



My five top takeaways from the Smart Architect session at CA World:

  • There’s an absolute consensus among the technologists that attended and our development staff that we, as a group, are focused on the right things
  • The variety of perspectives that we had in the room, a great cross-section of industry verticals and organization sizes, brought significant value to the discussion
  • The cloud is still not clear to a lot of business users, business analysts, and people who require or rely on IT to provide services
  • Security remains an important discussion, specifically security for the cloud. Discussion had some very interesting takeaways; particularly around social media authentication and how identity is evolving into the new perimeter for most organizations
  • There is unanimous support for the idea of DevOps as an important movement. It demands embracing new paradigms, and new approaches that include everything from new tools, new solutions, new organizational structures, and new processes -- up to a complete revamp of the ways we approach solving problems, in order to meet cycle times


This year, the participants in the Smart Architect program really came together in developing their presentations, their stories and their message. While the program has always been grounded in the practical, I think the audience got even more value out of it than ever before. It was interesting just to note the different positions, the different levels of experience and the different points of view on each of the technologies. There were certainly a lot of very good technology discussions especially around some of the innovations we’ve done in cloud security. Smart Architect has evolved into an incredibly exciting, very well-received program. I was pleased to have it be part of the tremendous buzz I was feeling at this year’s CA World.


Every day businesses face unwanted disruption in the form of revised regulations, security threats and breaches, natural disasters, new competitors and digitization — not to mention rapid-fire customer demands.



While employee bring your own device (BYOD) trends and technologies such as cloud are at the heart of some business disruptions, IT can also use emerging technologies as solutions to keep enterprises leading, instead of lagging, in their markets. In other words, I wondered, can IT help anticipate disruption and even make it a competitive advantage rather than a negative? I spoke to analysts and IT execs to find out.



In particular, I was told that enterprise architects — as the system designers and process implementers in their organizations — can, and already do, offer protections that prevent or ease threats to business continuity and profitability.



Here are five ways enterprise architects can continue to help the organization be more proactive:



1. Understand the true business requirements for uptime and availability. Too many IT departments make incorrect assumptions about business requirements and their most critical processes and services, says Rachel Dines, Senior Analyst at Forrester Research, Cambridge, Mass.



Instead, “it's critical to conduct a business-impact assessment and work with line-of-business and application owners” to understand what they consider the most critical business processes, applications and IT systems to back up in the event of a disaster. That way, you can determine recovery and availability objectives jointly, Dines told me recently, and enterprise architects can prioritize according to business needs, not their own preferences.



Of course, they should embed availability and resiliency into every aspect of IT — not just infrastructure, security and operations, Dines says. Application development, corporate-wide enterprise architecture and external sourcing are all mission-critical as well.



2. Conduct “fire drills” and plan ahead. Greg Meyers VP, Global IT, at biotech company Biogen Idec in Cambridge, Mass., advises enterprise architects to prepare businesspeople for contingencies as much as possible. While there are many tasks IT performs routinely in terms of data backup and service continuity — for example, hot-swapping, mirroring, redundancy in the cloud and virtualization — “IT systems aren’t perfect; they will go down,” he reminds us.



“The table stakes are in getting the infrastructure to be as resilient as is affordable,” Meyers told me, but actually sitting down with business partners and running them through a simulation can remove some of the helplessness that is often felt when things do fail.



No company can predict every possible risk it will face, so the experts say to start with the most likely and those that would have the greatest impact and address those first. You can also use predictive analytics to help forecast the likelihood of certain outcomes or risks — from winter storms and hurricanes, to security threats such as denial-of-service attacks. “Build out more plans for different types of risks,” Dines says, and “make sure risk assessments are kept up-to-date.”



Companies that tie their updates to a change-management or release-management process will be more successful, she says.



3. Consider using cloud services. The cloud itself can be a business disrupter because it changes the way IT services and apps are delivered to end users. But the cloud can also provide data and application access when in-house resources are not available.


Enterprise architects need to look at how cloud services fit with existing IT architectures and determine where it makes the most sense to deploy hosted offerings. This can include infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), as well as the most commonly used software-as-a-service (SaaS) offerings. Enterprise architects should offer business managers their advice on which apps to host and which to keep on-premises.



4. Leverage DevOps. DevOps software development methods emphasize collaboration and integration between IT and business operations and the development team. The goal is to automate processes as much as possible to help enterprises more quickly build applications and services for users. That’s a big step toward to easing business disruption.


Specifically, DevOps helps companies manage software releases by standardizing development environments. Progress is tracked more easily with this approach, and problems are detected and resolved more quickly. DevOps can also improve reliability and security, as well as offering faster development and deployment cycles. Adoption of DevOps is being driven by agile and other “lean” development processes and methodologies and also by demand for quicker application releases from business users.



5. Initiate DevOps together with agile software development. When agile development -- software development methods based on iterative and incremental development — is used well, companies build better and more reliable applications from the start. Business users or customers provide feedback on features and capabilities during the development and upgrade phases, not after the fact.



In this way, application development can stay ahead of changing business requirements and not be caught unawares when business wants something new. Since developers and users collaborate frequently, there is less likelihood of a disconnect between what users need and what developers deliver.




I often hear of new tools, frameworks and open source projects that turn into the “excitement of the month.” It begins when someone in IT talks about the latest “software movement” in a hallway, which is when they try to get me involved. It typically ends with me feeling out of touch for not having already launched a project around it. The most recent examples are with big data frameworks with related NoSQL databases. NoSQL encompasses nonrelational, open source and distributed databases with simple APIs and frameworks such as Hadoop and Cassandra.



My perspective as a longtime enterprise architect is this: The challenge isn’t in keeping up with or learning about new technology and software — we do this all the time reading journals, attending conferences and speaking with vendors. The real challenge is keeping developers in check when it comes to these new ideas because they often want to jump on the bandwagon and try every new platform that’s released. The primary focus for an enterprise architect, therefore, should be building a technology stack for the business and meeting customer requirements. Letting developer frameworks and tools drive decisions and strategy could lead to extra work and extra costs down the road. I specifically recall the early days of Web service development and how some of the initial frameworks were lacking in the areas of security and administration.


Of course, enterprise architects do indeed need to keep up with and evaluate all of the latest in software tools and frameworks, and NoSQL databases definitely have their place in agile Web application development and management of big data and cloud, as this blog suggests. Quoting 451 Research, the article notes: "NoSQL database technologies are largely being adopted for new projects that require additional scalability, performance, relaxed consistency and agility."


Nevertheless, enterprise architects need a uniform evaluation formula for due diligence of all new technology and software. First, define a set of criteria, including these five areas:

  • Security
  • Stability
  • Standards
  • Talent
  • Costs (yes, plural )


It’s the architect’s job to look at things in this way because developers often don’t. Here’s a look at some sample frameworks and tools, and how to apply this formula for evaluation.



NoSQL Pros and Cons



I begin my evaluation of any tool with security. Despite their many advantages, big data tools, such as Hadoop, and many other NoSQL databases initially failed the security test. Hadoop, built on a file system, or NoSQL databases that lack the security features built into the big SQL databases, fell short because firewalls and routers don't equal a security strategy; they’re part of one. Fortunately, a more thorough evaluation led me to vendors that do offer Hadoop-based big data solutions with security built in, such as Zettaset, as well as Actian’s Ingres Database.


Stability and Standards:

Beyond security, you need to evaluate the stability of the software as well as the company or community that supports it — and that can be difficult in this still-maturing market. Ask yourself whether the product supports the set of standards you require or whether it defines its own? For instance, Facebook moved from Cassandra to HBase because HBase is built on an emerging standard. Ironically, this emerging standard is the Hadoop Distributed File System (HDFS), which is still very new itself.


Talent and Costs:

As for the rest of the enterprise architect’s evaluation process, understanding both the available talent pool for the tool in question and all of the costs involved is crucial. Deploying a wonderfully secure and stable solution on a technology very few developers understand is risky. This leads to one of the hidden costs often overlooked by developers when using so-called “free” open source software. Bugs, support, hidden license restrictions, lack of indemnity in case of lawsuits and so on are costs you need to consider and measure as much as possible.


Going forward, enterprise architects need to constantly evaluate tools wisely so we can take part in those hallway discussions when the next new tools burst onto the scene.




Using Communication Tools Wisely

Five criteria – security, stability, standards, talent and costs -- are valuable for evaluating more than developer tools, frameworks and libraries. They are also required when new communication tools and devices are introduced, whether they’re used internally or externally with customers.

For example, when instant-messaging (IM) tools burst onto the scene during the dot-com bubble and were used by developers, they increased communication with little hassle or disruption to most people’s routines. It wasn’t long before IM was used to communicate with customers as well, which also had many benefits. However, many failed to see the downside to this trend. Many IM tools and specialized Websites didn’t meet basic security and regulatory requirements.
Businesses failed to realize that IM conversations aren’t always recorded — never mind secure — but keeping corporate communications records is usually a legal requirement. As enterprise architect, it’s your job to make sure these requirements are met as well.

Fortunately, new cloud tools such as Google Docs and Basecamp do meet the security and regulatory requirements for client communication and data sharing.




Eric Bruno is Principal and Technology Specialist at Allure Technology Inc., where he is focused on software design and applications.


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.


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.


Most large corporations attempt shared services out of necessity and common sense. After all, duplication is wasteful, and sharing services for application hosting and administration promises to reduce cost, complexity and waste. But while I’ve seen it succeed, more often than not it’s a struggle to satisfy all of your development groups without requiring too many exceptions to the development and deployment process — and that offsets some of the gains.


To get another view on the subject, I recently interviewed several IT executives, including one at a major financial institution, about their efforts with shared services. Not only is it possible to succeed, this executive said, but “We are doing it.” The biggest challenge he found “is supporting a robust technology stack without turning off projects” that are not on the list of common platforms. For example, the company has promoted shared platforms in four categories: Java, .NET, databases and general Unix deployments. The Java Application Platform was the first, and it has been in production for more than 10 years. “This is a shared services platform based on WebLogic server, Solaris (changing to Linux), and a popular tools stack. The servers are large core machines,” he explained, and developers must use the specified environments. If you turn off projects, you may fact downtime or poor service.


Getting everyone’s buy-in, therefore, is critical when moving from dedicated to shared applications. The first challenge is getting your development teams on board and willing to integrate their development cycle with the requirements of a shared services platform.


CIOs are often concerned that development teams will push to do what they please, despite the best efforts to build a common platform Another IT executive, who did not want to be identified, said that satisfying each development area is critical to adoption, but it is also important to tighten the reins to a degree. “If we were to support an ad hoc technology stack, it would not be feasible to perform proper testing, diagnose problems and provide support.”


Striking a Balance

The key is to strike a balance between meeting everyone's needs with a single platform and not requiring too many exceptions to the development and deployment process. A joint effort is needed. “To promote consensus, we form technical advisory groups (TAGs) comprising representatives of all areas of the bank, [who] agree on a technology stack,” said the financial services IT executive. “Once that’s decided, teams have to make a strong case to introduce competing technologies. If you need a technology that is not supported, you will generally be granted an exception — but a TAG will first review it and make a recommendation, he said.


Focusing on developers is only part of the story. Additionally, “maintenance of the technology stack is in the hands of the operations teams,” and end-of-life migrations can be hastened as part of their job. That’s an important point, since a common complaint is that shared services platforms tend to stagnate in terms of technology. According to the financial services IT executive, “We use a three-year strategy, and every year a new platform version is released. Applications on the previous release are notified that they will need to migrate within the year.”


Cloud-based Solutions

Building on standards-based systems has become more critical as enterprises explore the cloud and Platform-as-a-Service (PaaS) solutions, but views differ about which approach to take. “In a financial services firm, it’s difficult to get any traction on an external platform. However, a hybrid strategy is practical,” so you can “host non-sensitive data and applications on external clouds while keeping the rest more securely in-house”, the financial services executive said.


In my own experience, even if you never deploy to a public cloud, there’s still something to learn from them. The financial services IT executive I spoke with agreed: “We can learn from the cloud vendors about automated procurement, security and monitoring, and then build internal clouds based on industry experience.”


Overall, it is possible to build out shared services in the enterprise and reap the benefits. However, you need to have a close working relationship with each development group to understand its unique challenges. Here’s an example an IT executive presented: “Low latency applications have a special challenge. If every machine instruction is critical and a poorly timed, garbage collection can be expensive, some teams are understandably reluctant to run on shared hardware. But others take a more practical view and ask the operations teams to guaranty their Service Level Agreements.”


The key takeaway is that building a single shared services layer shouldn’t be a quest for a single holy grail, or a mandate from an architecture group. It needs to be a corporate-wide team effort where all stakeholders are involved, including the CIO, the enterprise architects, and the development and operations teams.


Stakeholders may question whether this centralization really benefits the business or affects business users in any way. “Actually, the goal is the opposite,” said the financial IT executive “[We aim] to tighten up the plumbing without impacting the business.” And since the cost savings are significant and the financial industry is operating under so many new legislative constraints, the push will continue. “The savings are integral to success.” It’s hard to question that.



Eric Bruno is Principal and Technology Specialist at Allure Technology Inc., where he is focused on software design and applications.


Some big names in the IT industry – Microsoft’s CEO Steve Ballmer, for example, and Adobe’s CEO Shantanu Narayen – have publicly said they think that the growth of the cloud for hosting software will lead to a decrease in software piracy. Software piracy costs an estimated $51 billion globally every year, according to IDC in its 2010 report, The Economic Benefits of Reducing Software Piracy. While these executives may be right about a decline in the problem of rampant use of unlicensed software that has long troubled tech vendors, the cloud actually may create piracy problems of another sort: The theft of data and services that relate to applications running in the cloud.


Sure, data theft always has been an issue for companies. But with data increasingly found on the cloud’s “open seas” – make that “open skies” – it’s so much more easily boarded and taken for ransom by modern-day Blackbeards. When that data is intellectual property associated with your services, imagine the potential for revenue hijacks. As an example of an incident foreshadowing these concerns, look no further than the case where SAP’s TomorrowNow division illegally downloaded Oracle’s online support material to provide Oracle’s own customers with an alternate means of software services. The suit that began in 2007 finally ended late last year when SAP was ordered to pay Oracle $1.3 billion in damages.


It’s time to start architecting a global defense against such forms of piracy. Your work starts with thinking about what defenses need to be shored up – whether, for example, security holes exist that will allow your data in the cloud to be stolen. Pirates might want to realize many ends from looting IP data, including digital terrorism where such data is held for ransom, or even to manipulate the stock market by creating a negative perception of a company's reputation.


Enterprise Architecture to the Rescue

The enterprise architect has perhaps the most critical role to ensure the right technology is used to fight this battle against pirates in the sky. My strategy for success is comprised of a multi-pronged attack:


  • Network architecture: Diversity matters in your stock portfolio and it matters for architecting networks that extend into the cloud, too. The cloud, platform choices, global distribution of services, and layers of abstraction offer enough obfuscation to thwart intrusion. Oh, and it leads to a more scalable deployment as well; win-win!
  • Data architecture: Design for encryption, keep (where appropriate)data within your private cloud , and watch out for enterprise mash-ups. For one thing, control access to your critical data where it’s required (i.e. financial data that require audited, metered, access). Beyond protecting the obviously critical databases, don’t overlook apps’ administrative and support systems whose data lives in the cloud.
  • Directional Authentication: Have your users come from a single, known source of authentication or clearing house to reduce the chances of intrusion. Alternatively, you can use two-factor authentication, which requires two forms of proof that your users are who they say they are.
  • Intrusion and Theft Detection: In some ways, it’s a losing battle to fight the bad guys. Just make sure you know the instant they’re at your front door. That effort requires coordination with CSOs.


Let me expand on those thoughts a bit, starting with network architecture. With the cloud, network architecture goes beyond adding firewalls and routers in all the right places. It means choosing a cloud vendor with security guarantees; distributing your services beyond a single hosting provider; and building a private in-house cloud to house your most critical business components—that is, black box algorithms, customer data, and other valuable IP.


In terms of your data architecture, don’t assume all threats are external; often the biggest danger comes from within. Both accidental data exposure, and ill-intent can put you and your data at risk. Ensuring that your data is encrypted within the confines of your own firewalls, and not allowing applications to use internal data without going through proper gateways, will help thwart internal attacks and risks (accidental or not).


All that said, it’s my opinion that intrusion detection is where you should put most of your time, energy, and money. Many companies offer products and services to help protect your software assets, as well as your customer data, from theft and piracy. For starters, authentication, authorization and auditing software such as CA SiteMinder offers you peace of mind that access to your cloud or web-based services is secure, while providing your customers with the convenience of single sign-on across your products and services. Other products offer security at other stages of online software usage, such as when users initially sign up for access to your software, or make self-service support requests. These areas often are overlooked in terms of their security needs, and strong identity management software is a must here.


You should consider user activity reporting software, such as CA's User Activity Reporting Module, which securely tracks your users' activity across your online software and services to identify potential security breaches. This type of activity logging is sometimes mandated, such as with SOX compliance, and HIPAA privacy laws.


Of course, your company’s CSO is responsible for a corporate-wide vision of security in every facet of the business. This goes beyond architecting security into an application or suite. So, while it’s your job to ensure the systems your company deploys are secure, it’s the CSO’s job to align this across all software produced, bought, sold, and acquired, as well as respond to security incidents, and deal with the exposure and liabilities associated. Therefore, when architecting a software product’s security detection and response systems, be sure to align with your CSO and her company-wide strategy for dealing with risk in this area. (This slidecast provides a lot of advice about working with your IT security team to help ensure that application security is built in, not bolted on.)


I’ll reiterate: While it may be impossible to prevent data piracy, the best defense may be early detection when it does happen.


Breaking the Pirate Code


To summarize, your architecture to thwart modern software piracy should include a combination of the following:

  • Obfuscation through a scaled-out PaaS/Cloud strategy (no single source);
  • Private cloud, where appropriate, for critical IP, and customer data, too;
  • Data encryption at the source, inside an internal walled garden (trust no one);
  • Directional authentication: single sign-on from a known secure source (i.e. CA SiteMinder), and/or two-factor authentication (such as CA’s Arcot set of solutions);
  • Detection, detection, detection.


You also might find it helpful to review some other articles Smart Enterprise Exchange has authored on cloud security, including Security and the Cloud Must Co-exist; Unlocking Cloud Security; and Cloud Security: From Barrier to Enabler. Also check out videos like this one Cloud Computing: The Enterprise Advantage Video Series.


Talk to an enterprise architect about the cloud, and you’re likely to hear him or her say that it’s an opportunity to cut future costs. Think of it this way: The enterprise architect sees architecture as a game of chess, with each move setting up future moves. Longevity of solutions also is desirable, since spreading a project’s costs over an extended lifetime increases cost-effectiveness. Therefore, the cloud represents savings in terms of future growth to the architect.


This is precisely what architects mean when they refer to an “elastic architecture,” or the elastic nature of a virtualized server environment hosted in the cloud. Future growth — and savings as that growth takes place — is assured by access to a virtually unlimited pool of hardware and software resources that are used only as needed, avoiding waste at every turn. (Full-service companies, such as CA Technologies, provide elastic cloud solutions with application management services built in.)


Cloud: Scale of Economy


Wait, the economic benefits don’t end there! To the enterprise architect, the savings value goes beyond elasticity. The cloud adds another layer of abstraction and simplicity to the enterprise application environment. As any good enterprise architect knows, abstraction leads to reward, because it removes an otherwise complex set of components from the equation and replaces it with a single, manageable square on a white board.


This square can then be contained and controlled — and further, it can be labeled as someone else’s problem. That someone else is the cloud provider. The cloud fits this square, and this description, perfectly because with it, the enterprise architect can design solutions that are quicker and easier to develop and deploy. And whenever you see quicker, or easier, think $$.


Cloud vendors can offer an enhanced application environment at a reduced price because of the economies of scale. After all, they’re providing comprehensive hosting solutions to a potentially large number of enterprises, and can pass along the savings that come along with this volume. The architect that taps into the scale of the economic savings this represents will save his or her enterprise money with compound returns in the future.


A Rose by Any Other Name


Here’s the twist: Many architects won’t cite “cost savings” verbatim as their driver toward the cloud. Instead, they may characterize it as a drive toward simplicity, allowing them to focus more on the real business solutions they’re tasked to design. But if you probe a little farther into that statement of simplicity, a good enterprise architect will explain how simplicity results in better security, improved performance and quicker application deployment.


I hear cost savings when I read that, don’t you?


Here’s how this played out in real life for me in a recent project I was involved in where key client components were moved to the cloud:


- The number of components installed on the client side was greatly reduced, which simplified the deployment process and reduced the chance for error during download.


- With the bulk of the business logic that once ran at the client site now up in the cloud, performance was improved and made more consistent; no longer was there a reliance upon varying client hardware capabilities to execute.


- Security was greatly improved, and simplified, since the client components that once had to navigate client proxies and other network security provisions were moved up into the cloud, and accessible over standard, and secure, web protocols.


- Management was simplified and outsourced to the cloud provider, and support staff was no longer required to manage issues with client downloads and server access issues.


Can you hear how that adds up to cost-savings now?


In an upcoming blog, I’ll discuss why the enterprise architect should be focused on efficiency and cost in every decision he or she makes.


In the meantime, you may want to explore the cloud economics issue further by reading this blog written by Smart Enterprise Exchange editor and community manager Paula Klein, as well as this article by Doug Bartholomew.


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 21st 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?


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.








In implementing enterprise architecture practices over an existing IT culture, alignment of resources is a critical step.  In dedicating resources to focus on policy and architecture and separating engineering and operations, rifts can form that cause problems with execution.

Often, established teams are separated to focus on engineering, operations, and architectural planning (or some similar permutation).  Time is initially focused on knowledge-transfer.  This leads to efforts to put in place formal rigors supporting enterprise architecture concepts like architectural reviews, a building-permit model, technical architecture standards management, etc.  While these focus areas help teams increase their depth of capabilities, they often lead to situations where de-coupled groups are no longer working as efficiently on delivery.

I have had the opportunity of driving the principle team responsible for IT Security at CA. Recently I moved my policy and planning functions into an emerging Enterprise Architecture practice and saw a skilled protégé assume the daily operational and engineering oversight. While we have been establishing formal engagement processes and mapping our interlocks for things including roadmaps, annual fiscal planning, and risk management, we have seen the shift from IT security being a one-stop shop into a divided set of teams that need to act as one in order to execute effectively.  A robust IT organization practices enterprise architecture and end-to-end operations seamlessly. The challenge is to ensure that the operational/execution organizations and the policy/planning functions communicate tightly around resourcing projects to ensure proper execution.


While there is no silver-bullet approach (one-size will not fit all IT organizations), we have found that spending time on the interlocks and addressing the possible rifts proactively and at the root-cause of issues has helped ease this transition.  While this is not a unique problem, it would be very helpful for IT organizations undergoing this kind of transformation to see suggestions on how to overcome the challenges of de-coupling EA and Execution.


What are your thoughts?  Please use the comments to chime in.



Contact Us

We encourage your feedback. Reach out via the "Contact the Editor" and "Contact the Concierge" services for any needs, questions or comments. We look forward to serving you!

Paula Klein, Smart Enterprise Exchange Editor
Ellen Lalier, Smart Enterprise Exchange Concierge

TwitterLinkedInShare Smart Enterprise