A few weeks back I wrote about the benefits — and challenges — of a federated architecture. In that blog I wrote that such an approach helps the enterprise architect organize the efforts of disparate groups to avoid duplicate software project silos, but also that the approach won’t get far without buy-in and cooperation from business users, data owners and various other stakeholders. (For a more detailed refresher, see the original post here).

I mentioned there that I’d be following up the post with another to discuss a project I’ve been involved in to tie disparate financial systems into a federated portal, which included taking mobility into consideration early in the design process.  I know you’ve been waiting for it, so sit back and enjoy as I delve into the how of architecting that federated effort! I hope my experience will help prepare you for issues that may arise with federated systems in your own enterprise, regarding security, deployment coordination and user interfaces, which is where we’ll start.

Dressing for Success

The enterprise architect’s first challenge will be getting agreement on a unified presentation strategy. Without standardizing on a single presentation technology, you risk a user interface (UI) that looks disorganized and disjointed. Equally bad, you lose the ability to share design patterns and code across software projects, and developers remain in silos, jeopardizing the agility that can occur when they are free to share their talent with, or even move to, other development groups to create added value. Technical problems, such as OS resource competition and varying data refresh rates, are bound to arise as well.

The Web-based portal I’ve been focused on building is for a set of applications — involving multiple development groups — in the banking space. Being Web-based, HTML makes up most of the UI. But because the portal is to be a rich Internet application, we had to get agreement on which more complex UI elements we would leverage for displaying dynamic data (financial market data in this case). Ajax, Silverlight or Flash technologies were in the mix, but trying to combine them all adds up to a sloppy presentation. As the enterprise architect on the case, it was important to listen to the arguments on all counts, and in addition mobility features had to figure heavily into the final verdict. Flash is a good cross-platform, cross-browser choice for dynamic UI development, but even better, it’s turned out to be a real star in the world of mobile devices.

Just Log In

Another area of focus in federated architecture is user authentication. It’s absolutely necessary to build a single sign-on (SSO) solution—not necessarily one based on SAML (Security Assertion Markup Language), but one that’s web-proxy friendly—that unifies the login process for your internal applications. But it’s just as important to enable access from external domains, such as those of your customers and business partners, seamlessly and without sacrificing security.

Solutions such as those in CA’s Identity and Access Management suite, provide capabilities that can work in your enterprise, across the Web, and even extend to the cloud. A single sign-on product, such as CA SiteMinder®, is specifically built to solve this problem, as shown in Figure 1. 

Figure 1 - How Single Sign-on Works (Illustration credit: CA SiteMinder Product Brief)

Here’s how it works:

1. The user accesses a protected resource.
2. The user is challenged for credentials, which are passed to a secure SSO agent, such CA SiteMinder.
3. After passing through another layer of network security, the credentials are passed to a policy server.
4. The policy server securely authenticates the user against the correct data store.
5. Entitlements are passed back to the policy server where access is granted.
6. The user’s profile data is passed to the appropriate application(s).
7. Appropriate application content is provided to the authenticated user.

Remember, in a federated solution, all of your organization’s secure applications need to be unified within a single SSO solution, and all of your user authentication must be accessible within a single set of data stores. 

Deployment Demands

Another critical task facing the enterprise architect who drives a Web-based federated effort that runs well on mobile devices is the deployment and administration of services within the cloud. In my case, this involved a private cloud.

The main goals were to enable lifecycle and operational independence. The first mistake of some of the groups participating in the effort was that they placed their enterprise software components into the cloud as one large component. This quickly led to problems in the areas of scalability and ease of deployment.

As a result, I began an effort to break down all software components into sets of basic services with discrete tasks. We designed a way to easily deploy and dynamically execute these services across servers, both physical and virtual, according to a core set of capabilities and prerequisites. For example, information such as average transaction time, network bandwidth needs, dependencies on other services, and external resources and storage needs all are factors in deciding how many instances of each service are started, and where they’re located.

That’s why the system now can manage itself to a degree. However, administrators still can control individual services, migrate them across servers if problems arise, and roll out individual service updates without interrupting the entire federated system. In the end, the entire system and process is more agile, with limited dependency on specific developers’ expertise, or custom frameworks that duplicate deployment and administrative tasks. In summary, less human interaction equates to more efficiency, and reduced duplication equates to reduced costs and greater shared value.

Looking Ahead

If you’re interested in moving your enterprise toward a federated architecture, you must understand that you’ll need to constantly engage in forward-thinking and proactive planning, since unification efforts take a great deal of time and need to be flexible. That’s especially true as new development groups come on board and various databases need to be consolidated.

But as most enterprise architects learn early on, a good architecture is never complete. It just continues to evolve over time. We’d love to hear about any of your own evolutionary experiences as an architect.

You know it and I know it: Most large organizations suffer from silos, with duplicate software projects in active development. The reasons for this vary — a political power-play, an accident, a belief that it's easier to reinvent the wheel than drive someone else’s car.

But the results, as every enterprise architect knows, are the same: Duplication is costly, and ultimately it eats into the organization’s ability to function as an agile enterprise — that is, one that can freely and spontaneously exchange information as a whole, and where new initiatives are taken on by many people working collectively, instead of only a few working in isolation.

How to wrestle this problem to the ground? I suggest thinking in terms of the federated architecture pattern, an approach that focuses on software, processes and developer behavior. This approach leads to a more agile organization, as it fosters interoperability between lines of business and information sharing. John Zachman, creator of the Zachman Framework for Enterprise Architecture, has positioned this approach as a practical way to employ architectural concepts in complex, multi-unit enterprises. And he has noted that its success requires someone (YOU) figuring out and actually creating and managing what is to be federated — i.e., that which is to be centralized, optimized, integrated and reused by the overall enterprise. (You may want to read Smart Architect’s interview with John Zachman on recent changes to his framework here.)

Building on Zachman’s definition, federated architecture is more than a fancy term to describe an enterprise-wide approach to software. It's a model to share concerns across the enterprise, and to identify common business problems, infrastructure requirements, development efforts and data needs. It requires, in effect, that you build a system that encompasses the entire organization, so that the business is able to adapt to changes in the market more quickly and efficiently, and in a much more cost-effective manner.

As Fig. 1 shows, a federated architecture solution provides the platform to align disparate systems, data sets, other internal and external cloud-based systems, legacy systems, and infrastructure, all via an organization-wide taxonomy. From the purely organizational perspective, this is a difficult task: You need to align the business, the data owners and all stakeholders, the corporate IT strategy, and all of development. And if that weren't difficult enough, there are technical hurdles beyond the norm.

Indirectly related to this is a means to perform communication and integration across the components: Complex event processing (CEP). CEP involves designing your systems to respond to events that occur across all layers of the organization's IT systems. CEP, which in a federated architecture goes way beyond plain-vanilla middleware, becomes a driving force of systems integration and higher operational intelligence, and as such requires corporate wide buy-in and cooperation. Successfully accomplished, the result is a unified architecture, and a common development approach, for all of the systems in the enterprise — no more silos.

Integrating this into the cloud also ties into everything we’ve discussed here over the past year: further reducing costs, increasing efficiency, and raising overall system quality and uptime. (For more on those issues, see, for starters, Time to Revisit Your Cloud Strategy, Architecting the Cloud: Which Workloads Should Move First, or A Technical Perspective On Which Workloads Should Move to the Cloud.)  It also leads to that elusive agile enterprise, where individual components within the architecture — and the people involved — are part of a larger system, one where changes and improvements affect the organization as a whole, with benefits shared. 

Additionally, the federated approach helps to achieve operational independence: Developers for one part of the system can help (or even take over) when emergencies arise in other parts. Examples include software failures, architectural deficiencies and changing requirements that demand additional expertise. Being able to quickly find others within the organization to plug in and help in these situations is a big win. This is a key value that’s lost in the “silo approach.”

For the past year, I’ve been involved in a project where a set of disparate financial systems are being integrated into a single federated portal. As the system brings together elements of trade execution and supporting analytics, the problems have been wide and varied, from normalizing technology selections, to ensuring data-access rights, to meeting latency requirements.

In an upcoming blog, we’ll explore an architectural solution for a federated system based on this real-world experience. Your own federated systems will vary, and of course they don’t need to be a Web portal solution specifically for these lessons to apply. Regardless of what you’re building or integrating, you’ll face the struggles of coordinating numerous stakeholders across the organization, getting them to agree on an architectural direction, aligning their schedules and deployment plans to one another, and truly implementing the systems according to the agreed-upon plan.

In the meantime, let us know if you have an example of how you have implemented a federated architecture to drive agility – and how you did it. 

Preparing software for SaaS delivery makes us 100% aware of what it takes to deploy, maintain, upgrade and integrate software. Intelligent restructuring of the application into containers changes the economics, quality, tools... everything. As someone who is part of the team that is building CA Technologies' SaaS from the ground up, the transformation has been fantastic. It is like seeing a child suddenly start to walk for the first time, and two months later, begin to run; it completely changes how everyone thinks. 

Instead of talking directly about the planning, architecture, technology and requirements, etc., here I want to talk about transformations I have already experienced. The first of these is the engineering transformation from agile as we know it to a systematic agile for a complex SaaS environment.

Today, CA Technologies has a unique opportunity to compose a next-generation SaaS Platform. We have experience delivering Clarity On Demand and have made strategic acquisitions such as 3Tera and Nimsoft. Worried about highly sensitive data? ADP has your income statements. Programmability?  SalesForce built that into its SaaS model. Standards? They exist, just need to pick the right ones to create this SaaS Environment. The pieces are all there.

In my next post I’ll talk about how CA AppLogic is a key to systematizing end-to-end build-to-delivery of SaaS and I'll introduce you to life before first bootstrapping of our SaaS environment.

Let’s face it: The IT Infrastructure Library (ITIL) is the 800-pound gorilla in the world of frameworks. In so many respects, ITIL has had a tremendously positive impact on the ability of companies to deliver IT service support capabilities. Yet, over the course of its 20-year history — particularly with version 3 — the ITIL framework has had applied to it some extended interpretations of just what it is and does. Some have concluded, for example, that it offers best practices for portfolio or service management, when in fact ITIL doesn’t even specifically define good processes for IT infrastructure and operations disciplines such as change management. Rather, it offers guidance, not “must-do” mandates.

These expanded notions of ITIL’s domain, though benign in intentions, have sometimes created tensions among various communities in the enterprise. Application developers didn’t necessarily appreciate ITIL V2 delving into application management, seeing it to be outside the role of the IT infrastructure and operations staff – the target audience for ITIL guidance from the outset. And enterprise architects may have felt their own Open Group architecture framework (TOGAF) territory was invaded by the V3 Service Strategy book that, despite its excellence, discussed activities outside the traditional scope of IT infrastructure staff.

"ITIL was designed for and is almost exclusively consumed by infrastructure management and operations, and V3 caused some problems,” explains ITIL expert Brian Johnson, who was part of the U.K. government team that originally created the ITIL approach. Johnson has authored many ITIL books and now is Principal Services Architect at CA Technologies. An example, in his opinion, is that the Service Strategy book shouldn’t be in V3 of ITIL. “It talks about the whole issue of designing services from a marketplace perspective. It is a genuinely excellent book that addresses subject matter outside the remit of most in-house IT service providers (and ITIL consumers) and would have been better placed in one of the OGC Programme Management guides.“

The release of ITIL V3.1 in July is aimed at addressing some of the more contentious issues that have arisen, and it takes steps such as placing into better context where ITIL does serve as a best-practice framework and where it does not. In other words, for instance, it acknowledges that it is at the discretion of the organization how portfolio-, project-, or security-management fits with the ITIL framework, if at all. While it is entirely reasonable for ITIL-adherents to have ideas on how to work with other good practices and practitioners of other equally important disciplines, including enterprise architecture, ITIL is not best practice for these disciplines, Johnson says.

That comes as welcome news for many, (enterprise architects not least among them!). Perhaps a lessening of friction among parties may lead to better relationships among enterprise architects, developers and IT infrastructure professionals — relationships that could be quite healthy for enterprise efficiency and productivity, too.

So Happy Together

Enterprise architects, application developers and IT infrastructure staff, for example, may want to put their heads together and revisit ITIL V1 and its Software Lifecycle Support book, as well as the V1 Business Perspective series. (In particular, Johnson recommends the book ‘Understanding and Improving’).

These books, Johnson says, do not claim to offer best practices for development, programming, database design or any of those things. But they do provide guidance for IT operations staff working with those involved in service creation, which of course includes the development organization and the architects charged with setting enterprise standards for removing complexity from application portfolios and enabling business responsiveness. “The books just explained where the different pieces came together,” Johnson says of the various elements that play into the software lifecycle. “Strictly speaking, that’s an Enterprise Architecture view.” And wouldn’t it be a good idea, he suggests, for enterprise architects and IT service professionals to come together at some point in the creation of new services and applications, so that they will effectively run on the infrastructure?

“It’s important to communicate how you can help one another,” Johnson says. Business services as well as IT services are bound to create storage, availability and recovery issues — all IT responsibilities and ITIL disciplines. So, when new programs of work are undertaken, it makes sense for enterprise architects to figure out what all the interfaces are, and make sure all the right people, IT operations included, are consulted at the right time throughout the design process. 

At the same time — given the weight ITIL has long carried in many organizations — enterprise architects, among others, may expect more from ITIL than what it in reality delivers when it comes to creating services. In which case, those expectations should be tempered: V3 didn’t provide a method to go from service strategy to service design.

“Right now, there is a disconnect between what an architect is probably expecting and what is delivered,” Johnson says. ”You don’t ‘design’ services using a catalog, for example. A catalog is where you put things. A catalog might offer reuse capability, it can store blueprints of designs, but it just cannot create new service designs.”

That said, the definition of design is often a moveable feast, Johnson notes, taking us right back to the importance of inter-discipline communications. “An operations manager might consider a new service to be, say, provisioning a server--but from a business perspective that would be an invisible component of a service that the business requires to process insurance claims in a different way. So the design will include inputs from many domain experts—including ITIL experts,” he says.

While ITIL does have a view on enterprise architecture, it is no more or less than a domain opinion on how best to interact with another domain’s best practices . Used incorrectly or as a blunt instrument, Johnson says, ITIL can in fact create more problems than it solves. But, as he also emphasizes, value will result when different parts of the organization come together to review earlier and current ITIL guidelines and come to their own interpretations as a group of how best to utilize them for the benefit of the particular enterprise. “It all comes down to attitude, behavior and culture,” he says, if enterprise silos are to be successfully bridged. “Stop talking and listen to each other.”

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office.

About the Expert:

Brian Johnson, CA Technology Services

Brian was part of the U.K. Government team that created the ITIL approach. Working for the U.K.'s Central Computer and Telecom Agency (now part of the Office of Government Commerce), Brian authored many of the ITIL books and designed both the ITIL business perspective series and version two of ITIL. He founded the ITIL user group (itSMF--and is an Honorary Life Vice President). His version one book, Software Lifecycle Support, written with software testing guru Richard Warden covered the roles of IT operations and development in designing IT services, one of the central tenets of the version three ITIL books.

Working with CA Technologies, he helped a major client achieve ISO accreditation for their IT operation. Brian has authored, or co-authored, more than 20 titles on ITIL, project management and related subjects. Putting theory into practice, he led both the first successful government implementation of ITIL best practices at National Savings, as well as one of the first private-sector examples at General Accident.

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,

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.

Building a cloud strategy can be a challenge, and moving existing applications to the cloud can be downright stressful. You don't want to miss out on the business and technical benefits of doing so, but you also don't want to risk disrupting customers in the process. 

In my previous blog on this topic, I discussed the business criteria around determining what should move out to the cloud. In this installment, let's explore the technical criteria — and rewards — to help determine which parts of your applications should move into the cloud

What Goes Up ... Stays in the Cloud

As an enterprise architect, your biggest motivation should be to solve business problems. But sometimes the reasons for an architecture decision are purely technical. And, in the case of cloud computing, what goes up will not come down, so to speak. When I've helped corporations build a cloud strategy, the main technical drivers for determining what should become a service have been the following:

·         Scalability: Will moving a key component into the cloud help increase scalability? If the answer is yes, this is a good choice. Sometimes, the cloud even presents opportunities to increase scalability that cannot be reached otherwise. For instance, REST-based services, with the low overhead of XML over HTTP compared with other component technologies (such as .Net and CORBA), provide extreme scalability. This scalability can be enhanced by Web-based technology such as highly tuned Web servers and load balancers. Also, individual services can be scaled differently, according to usage patterns. When part of a monolithic application, all of your components must be scaled identically.

·         Elasticity: Building on scalability, on-demand computing applies resources to a cloud-based service based on application demand. Cloud providers often offer provisioning services that automatically scale a service to meet demand, or provide management services to allow you control this according to key parameters – i.e. bandwidth, transaction rates, and so on.

·         Portability: Often, moving legacy systems to the cloud via Web adapters or an enterprise service bus can provide portable, platform-independent access to an otherwise proprietary system. Doing this can help expose a specialized system with a restrictive API, or with single-platform access requirements (i.e., a Windows API or a Unix signal handler) to other applications, regardless of platform or language. If you have a legacy application that's tied to a single platform or technology, consider moving it to the cloud (by building a cloud-based adapter service) for platform-independent reuse. Note here: service enabling an application can be a considerable task, and require a great deal of investment in terms of time and money.

·         Stateless components: If an application contains components where the logic is stateless by nature (i.e., transaction-oriented, message-oriented and so on), it is an easy candidate for the cloud. Moving these apps preserves their stateless contract, helping to further isolate their logic and more easily black-box unit test them. The benefits are often higher-quality services and applications, and a more iterative development and deployment process. For example, once moved to the cloud, the decoupled nature of the related services allows them to be revised and deployed according to their own independent schedule, decreasing the number of dependencies within a single application.

·         Data intensiveness: Software components that are data intensive (particularly around CPU loads) and thus usually requiring extensive database access can be moved to the cloud with many benefits. For instance, the cloud abstracts database access and hides it from the consuming application, as opposed to having access to a database scattered throughout your application. It also helps to provide increased scalability and performance, as you can scale and distribute a cloud-based service more easily than a database server.. Third-party technology, especially open source packages such as Terracotta's Ehcache, can yield benefits only when the applicable logic is moved to the cloud. If abstraction and independent caching can help your application performance, moving the applicable components to the cloud can quickly achieve this.

Administration

Crossing the boundary between business and technical reasoning, ease of administration is another factor to be considered when determining what can be moved to the cloud. For example, the cloud can help to remotely deploy, administer and configure individual components in new ways. Existing third-party software, such as CA Technologies' IT Management Software as a Service (SaaS) — is a good example of this.

Often, managing smaller, individual portions of otherwise monolithic applications in the cloud ensures quicker deployment, lower costs and greater system uptime. Simply put, if moving a component to the cloud helps you outsource its management, the cost savings over time can justify your decision. Centralizing administration in this way also serves as a gateway in your architecture, helping to fight duplication and wasted effort reinventing the wheel.

We’d love to hear about your own considerations around moving workloads to the cloud, both on the business side as we last discussed and on the technical end. Please weigh in on what factors into your discussions around business, technical and administration issues.

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.