It’s funny how often in life you become convinced that someone simply is closed off to your point of view — he or she doesn’t care about what you want to say and doesn’t have any intention of taking your concerns into account.

From personal experience, I know that happens when you’re a developer on a project trying to get a single application built and deployed, and when you’re an enterprise architect trying to define an enterprisewide technical vision. Both roles are important and crucial to the enterprise — after all, what good is an architecture without resulting applications? But it’s easy to get wrapped up in your role and your concerns and forget that the other party has concerns, too.

In one specific case, I recall sitting with my VP of development, explaining that we had an application to build and customers to keep happy. The enterprise architect and his VP were sitting across from us and were, I thought, entirely too dismissive of our situation and our need to circumvent parts of the architecture to deliver something fast.

Soon after this meeting, though, I had one of those moments where I just got it. It wasn't that the enterprise architect didn't care about “my application” — it was that he was thinking of the enterprise's current applications, and future ones. The enterprise architect needs to look farther down the road and position the enterprise to be ready to meet future customer needs more quickly than competitors. I approached the enterprise architect, hat in hand, and we cooperated from that point onward. You see, it turned out he actually did understand where I was coming from, too. As a result, we improved the architecture, and the application truly did benefit from the enterprise architecture's vision. And, I became an enterprise architect myself!

The point I’m making is that architects and developers must open up to each other and form a symbiotic relationship. One really cannot exist without the other. You've probably heard that all software has its architecture, even in situations where one isn't explicitly documented. This is why it's imperative to get it right, from the beginning. 

Improving Your Relationship

And embracing that symbiotic relationship also means getting things right all the way through the process. I once heard an enterprise architect say, “I don't do schedules!” By this he meant that he refused to get involved in the actual planning and development of the software he was helping to define. The developers understood that his job of defining the architecture for a large enterprise — and keeping it relevant — was demanding and time consuming, but he lost a lot of credibility with the dev team as a result of that attitude. You see, most people in development took this as a cop-out: They saw this as his attempt to remove himself from the results of his work if the architecture wasn't perfect, the software failed to meet customer needs, or if it didn’t deliver on revenue expectations.

Accountability all along the line is just as important as a clear architectural vision. In my experience, successful architects choose to be involved in the implementation process, and share in its ups and downs. This ensures two elements: First, development follows the architecture, and each developer becomes an advocate and a spokesperson for the architectural vision. Second, the architecture is sure to be improved as issues arise during development — especially those that weren't considered while defining the architecture. And there will always be improvements to make..

A good enterprise architect gets involved in the software's build process, testing and quality assurance, and ultimately its deployment. Remember that as the architecture process extends beyond the diagrams and models, into the development process, your success and relationship with development will grow as a result. In the next installment of this blog, we'll see how architecture can even benefit from popular development processes, such as agile methodology.

I’m sure you’ve heard, as I have, the debate over whether cloud computing could make enterprise architecture irrelevant, begun by Deloitte in the fall. Some folks in IT grumbled that Deloitte was off the mark in even raising this as an issue, but my read was that the consulting firm was grappling with a timely issue and considering all sides.

That said, I’d like to add my perspective about why the cloud most certainly does not make the enterprise architecture function irrelevant. It’s been discussed, of course, that accounting for business service organization and management — whether those services hail from the external cloud or not — is a key part of the enterprise architect’s role. Add to that the fact that enterprises are seriously invested in private clouds within their own firewalls, inside their own data centers, and managed with internal resources, or in hybrid models, and it’s hard to see how cloud computing can be separated from the enterprise architect’s purview.

Further supporting the case for enterprise engagement with private clouds are the following:

• Gartner sees private cloud investments outweighing public cloud investments for the near future. Its recent polls show that three-quarters of IT managers are deploying or plan to deploy a private cloud strategy by next year, and 75 percent expect to invest more in private clouds than in public ones through 2012.

• Cisco’s Connected World Report noted that one in three IT professionals will have more than half of the company's data and applications in private clouds within the next three years. The U.S., Brazil and Mexico are predicted leaders in private cloud adoption.

• In online polls conducted by Unisys at the end of last year, 80 percent of respondents said their organization was going to use a cloud, with the largest group (45 percent) specifying a private cloud. Twenty-one percent were looking at hybrid clouds.

• A Novell survey in the fall found that 89 percent of respondents consider private clouds to be the next logical step for organizations already implementing virtualization.

If private clouds can be thought of as services-oriented virtualization on steroids, think of all the issues the preponderance of private internal clouds raise for the enterprise, and, by extension, for the enterprise architect. For example:

• What structures need to be in place to scope up from hosting low-priority, low-critical apps in the private cloud to hosting high-priority, mission-critical ones?

• What governance needs to be assured so that you can enable maximum utilization and the elasticity that comes from a true internal multi-tenancy model?

• How can workload mobility be managed to intelligently account for policy or compliance within such models?

•      Does — or should — a virtual desktop infrastructure come into play in your private cloud architecture?

• What reference architectures are being road-mapped to provide design and best practices for porting workloads across what I like to call cloud cuddles (aka hybrid clouds), so that end-to-end transactions aren’t compromised?

Enterprise architecture, then, is no less relevant in cloud environments than it is to Web technology, XML or SOA. The enterprise architect’s domain still covers what goes into the ether (as my blogging colleague Eric Bruno has so intelligently discussed in entries like this one, and will in more to come), how those workloads scale there, and a whole bunch of other related issues. I’d argue that the cloud, in all its forms — private, public, hybrid — may very well make enterprise architects “ultra-relevant,” as systems and services are further distributed.

How are you adapting your enterprise architecture to your organization’s use of cloud computing?

Picking up where we last left off in our discussion of building your architecture to accommodate a growing mobile device infrastructure, today our topic focuses on: Data Delivery and Capacity Planning: Scaling to the Extreme.

With potentially thousands, or even hundreds of thousands, of new software clients instantly added to your architecture (often at a rate  throttled by your end-users themselves), mobile devices and their demand for data could put a strain on your data delivery systems. You need to determine the best way to distribute data to your mobile workers, which may not include the same infrastructure as your in-house users and their systems.

For instance, most remote data access will take place via Web-based portals and other applications over HTTP/HTTPS. If you don’t already have one in place, you’ll need to architect and build out a farm of Web servers and applications that communicate over firewall-friendly ports, such as HTTPS over 443. To make these applications more interactive, with live data and other rich features, Web 2.0 features such as Ajax and Comet (for streaming data over HTTP/S) will more than likely be desired.

Because your Web applications will need to deal with an unpredictable number of sustained HTTP/S connections for potentially large numbers of simultaneous remote users around the globe, a slew of performance and scalability issues await. Fortunately, emerging standards such as HTML5 with the WebSocket specification are addressing this issue.

Further, vendors such as Kaazing, Nirvana, Oracle and others offer solutions that scale, delivering and streaming data securely all the way down to the browser via publish-subscribe and queue-based channels (see Fig. 1).

Fig. 1 - Scalable Data Distribution [ILLO: Eric Bruno]

In this diagram, the WebSocket protocol, as implemented by a WebSocket server, helps scale data distribution over an existing Web network architecture. The HTTP/S protocol is “upgraded” to the WebSocket protocol (WS://), which eliminates the overhead that otherwise comes with each HTTP request and response. The end result is an efficient, scalable data distribution system that works with existing Web firewalls and network infrastructure.

Your business demands mobility, as dictated by your mobile workers and, more importantly, your customers. But you shouldn't have to sacrifice security or reliability to deliver it. Consider, for instance, that new versions of the system software used on mobile devices might introduce undesired behaviors that could have a catastrophic impact on security or availability? For example, when Apple released iOS 4.0 , there was a minor bug that caused a huge impact on legacy ActiveSync environments. So that’s something you want to keep in mind, too.

An enterprise architecture that's defined with a mobile device management (MDM) system integrated into all facets of your enterprise should help you achieve this, all while preserving your peace of mind.

Thinking about this topic, it’s become even clearer to me that every enterprise is bound to have its own unique problems in the mobile arena. What are your specific mobile application and data needs? Do they go beyond the management, security and data issues discussed in this blog? Feel free to discuss your situation, and share your thoughts with the community here.

According to Apple’s quarterly reports, more than 74 million iPhones and almost 15 million iPads were sold as of the end of 2010. Google’s Android and RIM’s BlackBerry are close behind in terms of market share, according to Nielsen’s State of the Media report for 2010.

There’s power in those numbers. Smartphone users — which include just about everyone in your company — can’t be ignored when they come clamoring for ever-increased access to more core applications across a broad range of devices.

That means that managing users’ demand for tools to do their jobs more efficiently and while they’re on the go is a huge priority (see related story) . So, in this blog and the next, we’ll explore what you need to be thinking about as it relates to architecting security and management infrastructure for multiple mobile devices; creating efficiencies across multiple platforms; and planning your physical architecture solutions to ensure capacity, clustering, security and so on.

Mobile Device Management (MDM)

Your first architectural consideration should be the management and provisioning of mobile devices in and across your enterprise. You need to consider the en masse provisioning of devices (ensuring that proper applications and security settings exist); how applications and updates are distributed to the devices (often via over-the-air distribution); and such other issues as remote monitoring, diagnostics, backup and restore, and asset tracking.

Standards need to be set and enforced regarding which devices will be used and how they will be secured, of course. Each platform has its unique strengths and weaknesses. For instance, Blackberry devices can be managed by Blackberry Enterprise Servers, and Microsoft devices can be managed with ActiveSync. The device's carrier should also be considered during the standards setting process; i.e. what are the monthly costs, limitations, roaming fees, and international plans?

The point is, if the enterprise architect doesn’t set the tone here, IT can forget about actually creating alignment with business goals. All available time will be spent just trying to keep the architect’s head above water as more phones, and ever more-capable ones, too, enter the workspace from a plethora of carriers, manufacturers, and based on a number of technologies Or worse, they’ll be building one-off solutions that don't integrate with the rest of the corporate architecture, usually creating increased security risks and making standardization at a later date more difficult. This can result in costly duplication of effort and conflicting implementations.

MDM software can include many ofthe components for configuring an entire fleet of devices, managing application installs and updates, security settings and even remote OS upgrades. MDM solutions can also allow monitoring, and remotely controlling, devices through over-the-air commands sent as binary short message service (SMS) messages. A typical MDM solution can plug into your architecture as seamlessly as possible, as shown in Fig. 1.

Fig 1. Mobile Device Management Architecture. Illo Credit: Eric Bruno

On the left are the mobile devices to be managed remotely. These devices may have management client software installed on them directly, or may be managed with the devices’ built-in features. In the middle are the central components of the MDM system that communicate with the devices via a well-defined and secure protocol — perhaps implemented with binary SMS, or over Microsoft ActiveSync or other proprietary systems like the Blackberry Enterprise Server (BES) solution. The provisioning servers work with your configuration management and release system to handle software releases and updates for in-house software, third-party software, and the OS. The MDM authority interfaces with your existing LDAP systems to manage user rights and controls for the mobile devices and their provisioned software packages.

However, keep in mind that not all mobile platforms expose integration capabilities to third-party applications. For example, Apple’s iOS devices limit what third-party MDM solutions can do to their phones. Some MDM solutions are certified only for specific phones from specific carriers, rather than an operating system.

The Open Mobile Alliance (OMA) has created a device-independent specification and protocol for device management, called the OMA Device Management initiative. It contains formal specifications and protocols for the various pieces in Fig. 1. Most device vendors, including Nokia, Apple, Microsoft and Sony Erickson, have built-in support for device management, many are even implementing the OMA standards. For the others, third- party vendors provide solutions based on the OMA Device Management that can be installed on your devices, Howver, the mechanisms to deliver OMA standards-based policies still vary across devices from different vendors..

Other independent specifications include the OMA's SyncML initiative, which specifically focuses on device and data synchronization. For more on the OMA and its protocols and specifications for device management, read here.

Don’t Let Mobile Device Security Be the Worst of All Worlds

It’s a mixed bag when it comes to securing data on mobile devices and ensuring secure access to the device for your applications. Some mobile platforms, such as Android, offer little security besides what’s present to protect the built-in applications and the kernel itself. In contrast, Apple and RIM specifically provide software and tools to remotely locate, lock and even erase devices if lost or stolen. Thinking ahead about lost devices   should drive the adopting organization to test and implement specific procedures..

Again, the OMA defines protocols as part of its MDM standards that specify secure content exchange, secure remote identification (of devices, applications and users), and user-profile management. But what about secure enterprise data integration? To fully benefit the mobile workforce, devices should enable more than just remote e-mail access. You need to synchronize calendars, contacts and communication with ERP, CRM and other enterprise systems — securely.

In general, you need to guard against unsecured wireless access, mobile malware, unguarded sensitive data on the device, and unauthorized network access. RIM offers the BlackBerry Enterprise Solution, along with its Enterprise Servers, to provide secure access to remote data. This includes device authentication over the carrier’s network, encryption of data sent and received, and digital signatures along the way to identify users and their data.

Device-independent products include CA Technologies’ Mobile Device Management software suite. Besides offering all of the management features mentioned in the previous section (over-the-air provisioning, tracking, software installation and so on), it provides security features such as inventory tracking, device scanning, policy-based identity and configuration, and integration with enterprise client management solutions. Other companies with security solutions include:

• MobileIron: MDM solution for iOS, BlackBerry, Symbian, webOS and Windows Mobile
  
  
• SyncShield: MDM solution for iOS, Symbian, Android and Windows Mobile
  
  
• Microsoft’s System Center: for Windows Mobile and Windows Phone 7 devices, with a Software-as-a-Service      (SaaS) management solution
  
  
• Columbitech: to secure wireless communication over various transport systems
  
  
• Sybase iAnywhere: for secure mobile access to databases, e-mail, as well as on-device data protection

Next time, we’ll look at how your existing enterprise architecture and its implementation may be affected by your mobile workforce’s data usage.

According to Apple’s quarterly reports, more than 74 million iPhones and almost 15 million iPads were sold as of the end of 2010. Google’s Android and RIM’s BlackBerry are close behind in terms of market share, according to Nielsen’s State of the Media report for 2010.

There’s power in those numbers. Smartphone users — which include just about everyone in your company — can’t be ignored when they come clamoring for ever-increased access to more core applications across a broad range of devices.

That means that managing users’ demand for tools to do their jobs more efficiently and while they’re on the go is a huge priority (see related story) . So, in this blog and the next, we’ll explore what you need to be thinking about as it relates to architecting security and management infrastructure for multiple mobile devices; creating efficiencies across multiple platforms; and planning your physical architecture solutions to ensure capacity, clustering, security and so on.

Mobile Device Management (MDM)

Your first architectural consideration should be the management and provisioning of mobile devices in and across your enterprise. You need to consider the en masse provisioning of devices (ensuring that proper applications and security settings exist); how applications and updates are distributed to the devices (often via over-the-air distribution); and such other issues as remote monitoring, diagnostics, backup and restore, and asset tracking.

Standards need to be set and enforced regarding which devices will be used and how they will be secured, of course. Each platform has its unique strengths and weaknesses. For instance, Blackberry devices can be managed by Blackberry Enterprise Servers, and Microsoft devices can be managed with ActiveSync. The device's carrier should also be considered during the standards setting process; i.e. what are the monthly costs, limitations, roaming fees, and international plans?

The point is, if the enterprise architect doesn’t set the tone here, IT can forget about actually creating alignment with business goals. All available time will be spent just trying to keep the architect’s head above water as more phones, and ever more-capable ones, too, enter the workspace from a plethora of carriers, manufacturers, and based on a number of technologies Or worse, they’ll be building one-off solutions that don't integrate with the rest of the corporate architecture, usually creating increased security risks and making standardization at a later date more difficult. This can result in costly duplication of effort and conflicting implementations.

MDM software can include many ofthe components for configuring an entire fleet of devices, managing application installs and updates, security settings and even remote OS upgrades. MDM solutions can also allow monitoring, and remotely controlling, devices through over-the-air commands sent as binary short message service (SMS) messages. A typical MDM solution can plug into your architecture as seamlessly as possible, as shown in Fig. 1.

Fig 1. Mobile Device Management Architecture. Illo Credit: Eric Bruno

On the left are the mobile devices to be managed remotely. These devices may have management client software installed on them directly, or may be managed with the devices’ built-in features. In the middle are the central components of the MDM system that communicate with the devices via a well-defined and secure protocol — perhaps implemented with binary SMS, or over Microsoft ActiveSync or other proprietary systems like the Blackberry Enterprise Server (BES) solution. The provisioning servers work with your configuration management and release system to handle software releases and updates for in-house software, third-party software, and the OS. The MDM authority interfaces with your existing LDAP systems to manage user rights and controls for the mobile devices and their provisioned software packages.

However, keep in mind that not all mobile platforms expose integration capabilities to third-party applications. For example, Apple’s iOS devices limit what third-party MDM solutions can do to their phones. Some MDM solutions are certified only for specific phones from specific carriers, rather than an operating system.

The Open Mobile Alliance (OMA) has created a device-independent specification and protocol for device management, called the OMA Device Management initiative. It contains formal specifications and protocols for the various pieces in Fig. 1. Most device vendors, including Nokia, Apple, Microsoft and Sony Erickson, have built-in support for device management, many are even implementing the OMA standards. For the others, third- party vendors provide solutions based on the OMA Device Management that can be installed on your devices, Howver, the mechanisms to deliver OMA standards-based policies still vary across devices from different vendors..

Other independent specifications include the OMA's SyncML initiative, which specifically focuses on device and data synchronization. For more on the OMA and its protocols and specifications for device management, read here.

Don’t Let Mobile Device Security Be the Worst of All Worlds

It’s a mixed bag when it comes to securing data on mobile devices and ensuring secure access to the device for your applications. Some mobile platforms, such as Android, offer little security besides what’s present to protect the built-in applications and the kernel itself. In contrast, Apple and RIM specifically provide software and tools to remotely locate, lock and even erase devices if lost or stolen. Thinking ahead about lost devices   should drive the adopting organization to test and implement specific procedures..

Again, the OMA defines protocols as part of its MDM standards that specify secure content exchange, secure remote identification (of devices, applications and users), and user-profile management. But what about secure enterprise data integration? To fully benefit the mobile workforce, devices should enable more than just remote e-mail access. You need to synchronize calendars, contacts and communication with ERP, CRM and other enterprise systems — securely.

In general, you need to guard against unsecured wireless access, mobile malware, unguarded sensitive data on the device, and unauthorized network access. RIM offers the BlackBerry Enterprise Solution, along with its Enterprise Servers, to provide secure access to remote data. This includes device authentication over the carrier’s network, encryption of data sent and received, and digital signatures along the way to identify users and their data.

Device-independent products include CA Technologies’ Mobile Device Management software suite. Besides offering all of the management features mentioned in the previous section (over-the-air provisioning, tracking, software installation and so on), it provides security features such as inventory tracking, device scanning, policy-based identity and configuration, and integration with enterprise client management solutions. Other companies with security solutions include:

• MobileIron: MDM solution for iOS, BlackBerry, Symbian, webOS and Windows Mobile
  
  
• SyncShield: MDM solution for iOS, Symbian, Android and Windows Mobile
  
  
• Microsoft’s System Center: for Windows Mobile and Windows Phone 7 devices, with a Software-as-a-Service      (SaaS) management solution
  
  
• Columbitech: to secure wireless communication over various transport systems
  
  
• Sybase iAnywhere: for secure mobile access to databases, e-mail, as well as on-device data protection

Next time, we’ll look at how your existing enterprise architecture and its implementation may be affected by your mobile workforce’s data usage.

Who hasn’t heard the old philosophical debate about the chicken and the egg? Well, some 2,300 years since Aristotle asked which one came first, the world learned that the answer appears to be the chicken. Last year, British scientists discovered that eggs can’t be formed without a protein that’s found only in chicken ovaries.

Right about now you’re probably wondering: What on earth does this have to do with enterprise architecture? Good question! Here’s how I see it: Enterprise architects confront their own chicken vs. egg scenarios every day. Which comes first — the business architecture or the technical/data architecture?

Taking a page from the work of those British scientists, we can agree that the answer is — or should be — the chicken. That is, the business architecture. That designation is based on the principle that the business strategy is, in fact, the starting point of enterprise architecture work, and the business architecture, therefore, establishes the boundaries and guidelines for all the other architectures. In other words, the business strategy hosts the “protein” that lets the resulting egg — the technical architecture — be formed.

Nevertheless, we’ve all been in situations where the reverse occurs. Beginning with the technical architecture sometimes has been seen as a less than ideal place to start, because it could lead to enterprise architects working in isolation from the business. Their end product, then, is at risk of being abandoned by the business. In other words, lacking those chicken ovaries, the technical architecture just can’t be formed right.

I don’t think that has to be the case, though. Frankly, approaching enterprise architecture from either perspective has its challenges, but also its opportunities. What’s most important is how the enterprise architecture program is created in the first place, and what the enterprise architect makes of that. If it’s thinly chartered, with an exclusively technical focus, problems such as the one mentioned above  likely will arise — unless enterprise architects view this situation as a chance to excel and deliver value within the scope of their work. From that success, narrow though it may be, they can gain support for increasing the enterprise architecture program’s scope so that more business resources are allocated to the next project.

On the other hand, when you start from a business architecture standpoint, challenges may include managing business staff who have no direct reporting relationship to you, and whose performance feedback is beyond your control. In that position, enterprise architects must be pretty savvy about using their personal power to influence business analysts, so that EA projects are priority workloads. Succeed at that, and you’ll succeed at capturing and cataloging the business dynamics of process and workflow and engineering your architecture around that.

Cross That Road

Whatever the initial approach, the main point is that you’ve just got to get started crossing the road. Odds are good that the chicken will join the egg, or vice versa, somewhere on your journey to the proverbial other side — if not right with this project than perhaps with the one that flows from it.

It’s very likely, for instance, that you will discover business-related issues for a project even if it began in a technical vein. In that situation, get these business stakeholders to the table when it’s time to advance to the next level. I experienced that myself when I worked in the entertainment industry on an architecture project chartered to create efficiencies for managing digital assets. What began with a focus on WANs, SANs and moving really, really big files, led to major business process and workflow challenges that would affect producers, directors and talent.

I’d love to hear about your “barnyard” experiences as an enterprise architect. What’s the starting point for most of your projects? Is there something about your industry or particular corporate culture that drives that agenda? How have you seen the business and technical architecture worlds intersect?