Chapter 6. Platform Development

“A ‘platform’ is a system that can be programmed and therefore customized by outside developers—users—and in that way, adapted to countless needs and niches that the platform’s original developers could not have possibly contemplated, much less had time to accommodate.”

Marc Andreessen

“A product is useless without a platform, or more precisely and accurately, a platform-less product will always be replaced by an equivalent platform-ized product.”

Steve Yegge

“For the first time we’re allowing developers who don’t work at Facebook to develop applications just as if they were. That’s a big deal because it means that all developers have a new way of doing business if they choose to take advantage of it. There are whole companies that are forming whose only product is a Facebook Platform application.”

Mark Zuckerberg

“One of the things I like about the computer that I use is that I can write a program on it or I can download a program on to it and run it. That’s kind of important to me, and that’s also kind of important to the whole future of the internet. . . . obviously a closed platform is a serious brake on innovation.”

Tim Berners-Lee

Architects are tasked with seeking solutions to business problems every day. The challenge is to find low-cost alternatives that provide the maximum strategic advantage.

Despite the initial cost of development, building and leveraging platforms can serve as one of the best investments companies can make to maximize their dollars spent.

This chapter focuses on the key skills and considerations needed by a software architect to construct or transform systems into platforms.

Platform Development Defined

Platform development is the process of transforming an application or concept into a base set of shared capabilities and ecosystems that can be leveraged by multiple applications or solutions concurrently (see Figure 6.1). Platforms enable common capabilities across multiple applications or solutions.

Figure 6.1. Platform development

The Elements of Platform Development

Platform development can have a dramatic impact on your ability to produce applications quickly as well as to support customers in new and integrated ways. The challenge is how to manage the platform development in a manner that is not dramatically more expensive or more complex.

There are three key elements of platform development (see Figure 6.2):

Figure 6.2. Platform development is made up of three key elements: capabilities, ecosystem, and guiding principles.

• Capabilities. These are the functionalities delivered by the platform that basically tell you what the platform can do.

• Ecosystem. This is the environment in which the platform operates. It deals with everything that surrounds the platform.

• Guiding principles. This is the set of principles used to guide and direct the development and architecture of the platform.

These elements define the essence of the platform.

The approach taken to platform development can be dramatically different depending on where you are starting. Are you designing a platform up front in a mostly greenfield development exercise, or are you backing into the platform from an existing application? The end state may be the same for both, but the considerations and costs for how to get there may be extremely different.

Capabilities

The core value of a platform is based on the defined set of capabilities it provides. These capabilities usually emerge from an application or a set of applications. With time, it is recognized that these capabilities are leverageable across a wide variety of applications. The challenge is how to package and distribute these capabilities to a wider audience.

Defining the Set of Objectives

Before diving into the set of capabilities for a platform, start working with the business to define the purpose and key objectives of the platform. That is, what will the platform help the business accomplish? This description usually contains three to five key objectives followed by a bulleted list that starts with words like enable, provide, broaden, adhere, and partner. These may seem like “mom and apple pie”–type statements, but they do help bound the scope and focus of the platform development.

Defining the Set of Capabilities

Normally, when I start thinking about the capabilities of a platform, I think about the high-level actions that the platform can perform, usually high above the API level that a developer would access. These actions, however, are relatively close to what a business person would think of with respect to the platform.

Ideally, as the capabilities are enumerated, the terms selected are from the domain of the user or at least terms to which users would quickly and unambiguously relate. This is usually the beginning of the logical architecture for the platform and typically represents the groups of services that the platform will support. If there are more than seven to ten services, consider providing a higher level of grouping for those services to help make the platform easier to conceptualize for users who are new to it.

Although your business partners may not be accustomed to thinking in terms of services or capabilities, it is worthwhile to partner with them and ensure that the names and words being used make sense to them. It will also help with the long-term advocacy of the platform if your business partners have been part of its inception and shaping.

I have had a fair amount of success by simply getting business partners in a room and whiteboarding the capabilities. The benefit of this style of interaction is that you can come up with an agreed-upon vocabulary for the capabilities.

Focusing on Leverageable Capabilities

When first starting to define the capabilities for a platform, it is tempting to include everything that you can think of and be all-inclusive. The goal should be to include only the capabilities that are known to be leverageable by more than one application or what may be leverageable in the future by other applications. If the capability is application specific, the application can provide the capability itself.

Be diligent about what is included in the platform; it should have a relatively narrow focus in the beginning and do a small number of things well.

Developing a Strong Conceptual Model

The platform capabilities are typically grouped into sets of related capabilities. These groupings embody the conceptual model of the platform and should naturally cluster together to form a cohesive unit.

APIs Are the Keys to the Kingdom

APIs unlock the value of the platform (see Figure 6.3). They give developers the ability to manage and access the platform. When designing the APIs into the platform, many crosscutting concerns need to be taken into account:

Figure 6.3. Managing the platform’s interface is critical to the applications that will be built upon it; they simply expect it to work correctly every time.

• What are the security concerns? Clearly defining identity management and access control in a platform is absolutely essential to ensure that the platform is a “safe” place for your partners to store and manage their data.

• What is the granularity of information that is transferred? Is it fine grained? Does the interface need to support large batch capabilities?

• Is the data model explicitly defined in the APIs? Or is the data access more generic where the information is not known to the system but is accessed mostly from a key perspective?

• What types of protocols and supported content types need to be established? Is this simply HTTP/REST with JSON? Or is this JMS?

• Where does service orchestration belong? Does it belong in the calling application or does it belong in the platform? Is there related workflow? What types of events need to be supported?

• Does the platform support inversion of control? If so, what types of configuration are required to support it?

• Do you have an API versioning strategy? It is unlikely that your interfaces are going to be perfect right out of the gate. The key is to get them reasonably close and allow for the platform to grow and mature as you learn more about the real usage and needs of the platform.

• How do you plan to deprecate APIs? As the interface definitions mature, old interfaces need to go away. Giving your partners a signal that certain interfaces are deprecated allows them to make necessary upgrades before remove interfaces.

Ecosystem

The ecosystem (users, ownership, management, development, costs, quality, integration, scalability, and security) that surrounds the platform is nearly as critical as the platform itself.

Platform Users

Knowing and understanding the users of the platform are essential to knowing how the platform needs to be owned, architected, marketed, and developed. Key aspects of knowing the platform users include the following:

• What is the nature of the customers? Are they internal to your company or external to your company or both? Are they administrators or users? Are they revenue generating versus internal versus free? Understanding the nature of the customer can help drive your SLAs, your security approach, your disaster recovery approach, and what features are essential.

• If the platform is internal, is the service being offered within a business unit or across business units? Negotiating across business units gets tricky, not as much from a technical perspective but from both a political and a financial perspective.

Having this knowledge can drive how you need to seek funding, how you oversee the platform, and how you manage platform-related projects.

Platform Ownership

There are many subtle outcomes to the decisions that are made for a platform depending on who within the organization is the owner. The owner of the platform needs to guide funding, oversight, pre-engagement materials, project intake and requirements management, on-boarding, and awareness and acceptance.

Platform Funding

One of the more challenging aspects of developing a platform is not only to get the necessary support to fund development work, but to get it funded at a level that supports the strategic nature of the platform. It often takes more time to develop, test, and maintain flexible, multitenant platforms than single-purpose applications with limited capabilities.

Funding a platform requires you to manage and determine the following:

• Who funds the work? Typically, there is funding from each of the business units that is leveraging the platform, possibly from a central technology group, or potentially from other business partners.

• What do you do with those who want it for free? There are always those who want to come in and use the platform for free or for very low cost. This can be possible once the platform is more established, if they don’t require development changes and their utilization of system resources is relatively low.

• How much of the development can occur for a platform partner without their contributing funding? The answer to this is usually very little unless the features they need are being funded by someone else or being funded by central strategic development dollars.

• Do you allow others to make decisions about strategic direction without funding commitments? The groups you want involved in helping make strategic decisions are those that have some skin in the game and are willing to commit financial resources to building and supporting the platform. They will have a natural alignment to making wise decisions with the limited funding resources.

• How do you fund bug fixes? There needs to be some form of support funding built into the maintenance of the platform. This often takes place as some form of charge-back to the business units that are leveraging the platform.

• How do you balance the needs of partners who have a lot of money versus the little guy who doesn’t have as much funding to contribute? Platforms need to account for everyone who is at the table. If only the one group with a lot of funding gets all of the resources and attention, you destroy the sense of platform community and the sense of fairness that need to exist. Having some form of voting or agreement mechanism that takes all of the core financial contributors into account typically works well.

• How do you ensure equitable investments? If there are multiple areas that can leverage a capability, how do you allocate the cost? Most of the time, it is first to market that pays; the others that follow typically get close to a free ride. This type of model limits the capabilities of the platform unnecessarily when they may be broadly needed. If possible, look for ways to broker a shared allocation of the costs. This is where the value of a platform truly comes into play; everyone gets a chance to benefit from the development dollars that others are contributing, and the amount everyone needs to contribute in the end is less.

• How do you allocate ongoing costs? For internal users, do you have a charge-back model in place as usage and scale increase? For external users, do you have a usage-based model for charging?

• Is this an external platform? Relationships with other businesses need to be worked through very carefully from both a development perspective and an operations perspective, but also from a legal perspective.

Funding platform development can be challenging, but the rewards can be significant.

One of the keys to successful funding is to have an evangelist on the business side, someone who can articulate the vision and business value of building, supporting, and moving to the platform.

When this is working well, you are able to collaborate across multiple partners in the development of new features. This enables partners to come in and create a new feature that they will leverage and pay for. Later, this development is further enhanced and paid for by a second business unit. Since these new features are developed within the platform, the new enhanced capabilities are now also available to the group that helped define the original feature at little or no cost.

This type of leapfrog funding helps create a sense of community around the platform development. Everyone is able to chip in a little to help get things built, and everyone is able to leverage the work that others add to the platform.

Platform Oversight (Steering Committee/Advisory Board)

The oversight of a platform is usually some combination of technology (including architecture) and representatives of the various business units that have an active stake in utilizing and improving the platform to meet their needs.

There is always a wide range of political issues that arise in determining the following:

• Who decides what work gets done? Ideally, each of the contributing business units has the opportunity to “vote” in some manner on which capabilities are addressed first, and that in turn allows them to help prioritize and negotiate for the platform capabilities that are most important to them.

• What level of the organization “owns” the assets? If one business unit “owns” the platform, the owning business unit usually appears to be getting an unfair advantage and access to the development team. One way this is typically addressed organizationally is to have a central development team that is not a part of any business unit own the platform.

• What is an equitable means of allocating work? Some organizations may not be able to commit the same level of funding or resources to the development of the platform. The key is to ensure that those who are at the table determining what should and should not get worked on have committed some funds to the game.

• Do you allow other groups to contribute work to the platform? Most platform teams are strapped for resources (time and people). If you allow others to work on the platform, you need to ensure that proper measures are in place to guarantee that the work being done is leverageable by all parties and not just a hack to meet one area’s needs. One way to accomplish this is to have a limited number of committers to the code base.

• Can you open-source the platform? Depending on the nature of the platform, you may be able to open-source its development and allow a truly wide set of developers have access to improving it. If, on the other hand, the platform is considered an internal strategic asset, you may not have an option to open-source it externally, but you may be able to open-source it within the corporation. If it is internal, you still need to work out the funding issue in terms of how people allocate their time when they are working on the platform.

• How will you demonstrate business value? A platform may not directly generate revenue for the business, but there needs to be an awareness of how the platform contributes to other applications and in turn enables them to generate revenue. If you don’t generate revenue or contribute to generating revenue, you will be perceived as an expense. Finance folks don’t like expenses.

Having a solid model for platform oversight is critical for the long-term success of the platform. It can enable the changing needs of the business to be incorporated into the platform and, as a result, increase the platform’s long-term relevance to the business.

Platform Pre-engagement Materials

Having a good set of pre-engagement materials ready for new potential partners can help get many of the early questions taken care of and prepare the partners to have more on-point questions that will make your first meetings much more engaging for both parties. These pre-engagement materials usually include

• Prerecorded product overview presentations. These will give the partners a sense of the capabilities of the new platform and begin to prepare them to understand potential gaps and potential early wins for their applications.

• White papers. From these, new partners can get a sense of what and how other applications that have integrated with the platform have been deployed, what uses of the platform have already been put in place, what kinds of business services have been integrated with, and other basic information about the platform and its future direction.

• FAQs. A set of frequently asked questions will answer common initial questions that nearly everyone asks when first approaching the platform team.

The more prepared you are for new partners to come onto the platform, the easier it will be for both you and the partners to get a quick jump start to actual use of the platform.

Platform Project Intake and Requirements Management

Developing a solid mechanism for ingesting new platform requirements, change requests, and defects is central to the long-term health of the platform. Some of the key aspects of successful project intake include the following:

• Providing timely feedback. When new features or changes are requested of the platform, getting back to the requester in a timely fashion (measured in days) is a best practice. Respond nearly immediately as an acknowledgment of the request. Estimates should be responded to within a handful of weeks. Most estimating requests come in with some sense of urgency and need to be sized quickly to enable the requesting party to make investment decisions in a timely fashion. For an architect, there is usually a very limited amount of time in which to determine the appropriate solution for most requests. Ideally for newer areas, a quick POC or two can help significantly improve the confidence level of the estimate that is provided.

• Dealing with conflicting requirements with an eye toward operations. Often when multiple requests are made of the platform, there are conflicts between the different requests and potentially conflicts with the platform’s long-term objectives. The challenge is balancing all of these needs. In some very true sense, you are managing to the common good while maintaining operational excellence.

• Aligning with company goals. As a platform team, your allegiance is not to a specific business unit but to the greater good of the overall company. Knowing and understanding the company’s strategic goals are critical to helping guide architectural platform decisions.

• Realizing that you are at least one step removed from the end customers. For most platform development, you and your team are not directly interacting with the end customers. There is normally another group, business unit, or application that is interacting with the “real” customer. Take the time to meet with the requester to try to gain a deeper understanding of what is really being requested, to determine what alternatives may be acceptable, and to get a sense of the priority of the different aspects of the request. Try to develop and maintain customer focus even if you are a few steps removed.

Managing project intake with excellence is essential to keeping a platform thriving in the ever-changing world of technology.

Platform On-boarding

Getting new partners up and running quickly on the platform is an easy and early win that can pay great dividends with respect to goodwill and a positive trajectory with your new partners. Taking the time to prepare for a smooth on-boarding experience will help with both the management staff and the technical staff of the new partners. A good on-board experience usually includes having

• Architectural overviews. These will give the new partners a solid conceptual and technical understanding of how the platform works, how it is structured, and what is on the roadmap for future development.

• Scripted live demos. Anyone on the platform team can create these.

• Trained staff assigned to new customers. Staff can take care of any questions the customers may have and ensure that questions are answered promptly. Early on in the process these tasks can be handled by the architects, but with an increasing number of clients they need to be handled by others to ensure good customer service as the platform demand grows.

• Rich reference implementations of common platform uses. These should be easy to download and run in a handful of minutes. This will help enable a quick and smooth “Hello, Platform!” experience for your partners. You want this to be easy and painless.

• An API explorer. This enables the development staff to play around with the platform in order to get a sense of the conceptual model that surrounds it and to give them a quicker start on developing on or against the platform.

Platform Awareness and Acceptance

Once you have started to develop a platform, creating awareness of it throughout the company or industry can be a challenge:

• How do you make others aware of your platform? How do you make people aware that the platform exists and let them know what is possible? Internally, having an executive sponsor can be an excellent way to get the message out. A sponsor typically has the connections to reach across the various business units to get things moving. Alternatively, going on road shows to the different business units is also another way to develop a buzz within the company. Externally, this is really the job of marketing and sales. However, anything you can do to have demos, training, and white papers prepared can help simplify their job.

• Do you have a roadmap of features and their timing? How do you determine what is on the roadmap? Is it demand based? The ability to tell the story of where you are and where you are planning to go will help give your potential partners or customers the confidence that if they make the commitment to move onto your platform, they will have a solid set of new features to give to their customers. It also gives them the opportunity to let you know of any gaps you may have and gives you a better sense of any adjustments you may need to make.

• Are you aligned with industry trends? Showing that you are aligned with trends within your industry or potentially adjacent industries will help both you and your customers keep up with the competition and ideally stay at least one step ahead of them.

• What is unique about what you are doing? Where is your value? Is that something other areas are willing to pay for? You need to know what your key value proposition is. What is the special sauce you bring to the table that makes you stand out against the competition? You need to be able to differentiate yourself.

• Do you enable quick application development? The ability for users to get up and running quickly on a platform is essential, and having default configurations of the most likely chosen options can help your customers do this. They can customize things later once they have had a chance to play around and get comfortable with the system. You need to get to “Hello, Platform!” with little or no configuration necessary. The ability to support self-service with appropriate documentation can go a long way toward enabling customers to get up and running quickly and help minimize your customer support costs.

The lack of simple reference applications demonstrating the use of the platform can be an impediment to platform adoption.

• Is it possible to start with a small set of core passionate customers? Ideally, you have the opportunity to hold off on having a broad customer base until the core of the platform is solid; otherwise, you will deal with mass operational issues and concerns and may destroy the brand you have worked so hard to develop.

• What is your name, brand, slogan, iconography, and so on? Who you are and the image you want to project need to be crisp and clear. Everything you do needs to be tied together and present a common brand. Working early toward having branding standards is critical. Anything that doesn’t align with the brand you are trying to project simply raises questions about what you are doing, either consciously or subconsciously.

Platform Management

Having a clear understanding of how the platform will be managed is important for clear direction setting and the stability of the platform as a whole.

• Who is in control of the capabilities of the platform? From an overall company perspective, picking the right group to own and manage the platform is important. You want to ensure that they will have their customers’ best interests at heart and not just represent the interests of the business unit in which the platform resides.

• Is there a central person who acts as the benevolent dictator of the platform, or is there a community process that manages the capabilities? Sometimes having a single person who can oversee, guide, and direct a platform can work out well. The key is that this person needs to have a great business as well as technology acumen. He or she needs to have the ability to sell the platform and to know how to drive development of the platform in a way that will best benefit the business as a whole. Alternatively, having a steering group perform this function can also work if its members agree on the overall vision they are shooting for.

• How do you share capabilities? From a platform perspective, you need to understand what the model is for people to leverage capabilities. Are you looking to implement a multitenant environment where there are common instances of the software that understand how to run in the context of a user on every thread, or do customers host their own versions?

• Where are other platforms going? Ideally, the platforms that are being developed throughout the company are following common standards, patterns, and guidelines to give a uniform look and feel to the work that is being produced. Uniformity will help reduce the ramp-up time for users of the platform and ideally minimize the ceremony of getting up to speed on it.

• Who has the ability to add code? Your development model can dramatically affect the controls that you need to have in place around the platform. Do you have centralized development, where a single group owns and manages the code? Or do you have a federated development model, where multiple groups can contribute to the code base? In either case, you need to understand who is providing the active oversight of the changes being committed to ensure that they are in line with the vision and quality of the platform.

• Are there design patterns that can help the adoption and operation of the platform? As the platform matures, try to identify and name the patterns and idioms that emerge. These can help raise the level of conversation that needs to occur during the development of new features.

• What about internationalization? The global nature of what most companies are dealing with today makes internationalization of a platform something that needs to be in place from the very initial development efforts.

Platform Involvement with Mergers and Acquisitions

Mergers and acquisitions can be a great way for companies to increase their revenue growth or to acquire new capabilities that are missing from their product portfolio. However, trying to bring in a new acquisition and “merge” its capabilities into the overall platform development model you are trying to hone and refine can be very challenging without requiring a significant development effort. To help minimize this:

• Have someone familiar with the platform involved with the acquisitions team to help evaluate the overall fit of the assets that are being purchased with respect to the platform.

• Have an understanding of how you would incorporate the new acquisition into the platform. Try to look for how closely the architectural styles will interact with each other. For example, the purchase may be for installed desktop software, but you have a cloud-based software as a service (SAAS) solution.

• Look for open-source issues, regulatory issues, and legal issues that may exist and reduce the overall value of the purchase.

• Get a clear understanding of any identity or entitlement issues.

• Understand the overall goals of the acquisition and merger. They may be more about revenue growth than platform expansion. If this is the case, those who are making the purchase need to be aware of the overall capability sprawl and customer confusion that may result from the purchase.

• Make sure the costs of the changes to mainstream these capabilities into the platform are accounted for in the overall cost structure of the purchase to enable the development work that will need to occur after the acquisition is completed.

One of the problems that can occur when the platform team is not involved in mergers and acquisitions is that duplicative capabilities may be bought by business units that are not fully aware of platform capabilities. This can lead to future issues when the business wants to centralize these capabilities and the redundancies need to be removed.

Platform Involvement with Consolidating Company Assets

As the development of key platform capabilities occurs within a company, working to consolidate related company assets into the platform can be challenging. Those who need to begin leveraging the platform may have little or no interest in giving up the control of the duplicative capabilities they currently manage. Others will gladly move to the platform to help reduce their overall expenses and to access new capabilities. The platform will enable them to focus on their area of specialization within the business. Having the right level of high-level executive directives and oversight to drive the right behavior within the business is needed to make the platform successful.

Platform Involvement with Divestitures

As the company expands, grows, and changes, it may choose to divest certain assets within its overall portfolio. This may be done for a variety of reasons. As you consider what is being divested, take the time to closely consider all of the integration points the divested area may have within the business. These include business systems, technology systems, services, hardware, networking, and staffing. A significant amount of effort may be required to untangle the divested asset and get it rehosted outside of your environment. There are usually a lot of hidden costs that are amortized across different business functions.

Be Cautious about Expanding Where the Platform Extends and Grows

As you consider the direction for the platform, you need to be aware of the willingness of the business to invest in a particular area. If the support is not there, be cautious about expanding into that area.

As a platform architect, be willing to consider taking the occasional “weird” app that doesn’t match your core capabilities to help expand your horizons.

The decisions you make will likely last at least a decade; choose carefully.

Platform Development

Normally the development challenges around creating a platform are more complex and need a more strategic-thinking set of developers than for other projects. Taking the time to groom the right team is critical to enable high-quality code that is leverageable.

• Do you use contractors? The challenge is that they cost a lot and may allow you to deliver quickly, but the risk is a loss of quality. Hire right.

• Are there ways for you to show off your new technologies within the organization and attract the top talent? You need to understand what areas are of interest and what areas cause concern within the development community in your company and region. This will help you craft your hiring message.

• How do you manage demand for the development of features? Heavy demand may cause adoption of the platform to slow down due to lack of access to development resources. You may have been very successful in selling the platform to others but not have all of the features to cover their “core” capabilities. These gaps need to be identified and placed on an overall architectural roadmap. This will give your partners a sense of when they can join the platform and the costs that may be involved in doing so.

• Does the development staff have a clear understanding of the quality of service you are seeking to deliver? Are they developing or acquiring tools to ensure this level of quality? Platform development requires high-quality code. Make sure that the developers have this in their mindset; that when features are being added they follow the standards your team has established; and that the operational tools for monitoring, configuring, and deploying are all fully accounted for.

• How are you managing operating systems, JVM configurations, and other tools or services? The level of documentation around a platform tends to be higher than for typical application software development. Appropriately documenting the runtime and other operational requirements can make transitioning new capabilities into production a simpler process.

• Are you transforming from application to platform? If so, try to minimally impact your current customers. You need their support, especially in the early days.

• When to tech refresh? You want to stay current with technologies as they advance to keep your platform relevant and avoid atrophy. The challenge is to do this in a manner that minimizes disruption and does not cause you to abandon current customers.

• What is the cost of any licensing or support with respect to certain technologies? You need to be careful about being too expensive. Your goal needs to be to maintain cost-effectiveness. The business needs both speed to market and low cost to help maximize profit and maintain market leadership.

• Where is the appropriate and cost-effective place to deploy? Should this platform be deployed on physical servers? Cloud servers? Virtualized servers? Or should it be some mix based on environment and demand? The right combination of deployment options can help you manage your overall costs. Using virtual or cloud deployments can help with your ability to move quickly into lower development and testing environments by avoiding some of the long provisioning processes that are likely to exist for physical servers. Do you need to perform large-scale testing efforts? If so, do you have the hardware infrastructure to account for them, or can you access one of the production sites to help? Routing live traffic to one of the other production sites can help get real-scale testing in and help minimize the cost of maintaining a separate scale environment.

• Are there requirements to be able to deploy the platform on customer sites? If so, who owns the deployment and upgrade schedule? Make sure these items are covered in any contractual talks with the customer. What kind of access do you need or will you have to the systems? What kind of support is required? How will this affect your documentation? How will this affect your ease of deployment? Are there service personnel involved? Can this be managed externally? Doing on-site deployments may address the security and regulatory concerns of the customer, but they dramatically increase the complexity and cost structure of managing the platform. These issues need to be weighed carefully within the business to ensure that this is an area that you are willing to commit to. Exploring secure cloud deployments that are in the regional or national boundaries of the customer may be an acceptable alternative. Ensure that whatever path you are selling to the customer is one that you have both the technical and operational depth to manage.

• How often and when do you do deployments? What impacts are there to the applications on the platform? How do you manage through API changes? How do you ensure minimal impacts to customers? Deployments have the ability to dramatically impact live customers. Regression testing can play a critical role in assuring that the new software will behave properly for all of the partners that you have on your platform during deployments. You need to ensure that your API changes are versioned and that your changes are backward compatible. You need to ensure that as you do your deployments you have drained the site or instances in a manner that does not impact live customers. You need to message your changes to partners far enough in advance that they can react and plan for any changes that may impact them. The challenge with most platforms today is that there is an expectation of their being up 24×7. Having the ability to do rolling deployments, to roll back changes, to turn features on and off at runtime through operational controls, and to be able to target the release of features to a limited set of users or partners are all areas of concern for large-scale platform development.

• How do you manage your intellectual property? Have you applied for any patents? Do you regularly meet with an intellectual property lawyer to determine if there are any ideas worth pursuing for a patent? Taking the time to ensure that all of the work you have done to build the platform is protected is important from a business perspective. It helps the business to manage the platform as a financial asset for the company.

Acknowledging the Costs Associated with the Platform

Developing platforms is a fun and exciting endeavor. However, the development, maintenance, and operational costs are higher than for other projects. Unless the ability to significantly leverage the platform exists, it may not be worth the investment required to support the associated costs (see Figure 6.4).

Figure 6.4. Platform costs: building platforms is an expensive proposition but with many benefits.

There is also added risk to the set of applications using the platform due to the common dependencies of the platform if something goes wrong. If the applications are not properly managed, they also have the ability to impact one another.

Platforms raise the promise that they can create an environment where the time and effort to develop applications is significantly reduced and the costs associated with managing the operations can be shared. This can enable the businesses that use the platform to invest in other areas. Determining the actual costs, cost savings, reduced risks, improved product velocity, and other measurable positive benefits including attributable revenue can be challenging for platforms due to their multidimensional nature.

Managing Platform Quality

The quality of a platform is directly related to

• Focusing on loose coupling between capabilities.

• Aiming for a high percentage of code coverage. Focus on the error paths through the system; the happy paths will take care of themselves.

• Encouraging a high level of mocking. This helps focus tests on the class being tested, not its dependencies, including other classes and time-consuming resources such as accessing databases.

• Managing tech debt. If there areas of the code that everyone is afraid of, get rid of them; they will cause entropy to occur in those areas of the system and cause everyone to naturally want to steer clear of them.

• Performing a variety of different kinds of tests (functional, scale, ad hoc, automated, end-to-end, and user).

• Determining the time frame of backward compatibility. If you extend backward compatibility for a long time, it adds to the complexity of the code base; if you don’t, you may be forcing changes on your customers who are not in a good position to deal with change.

• Being cautious about database and data model changes.

Platform Integration

Understanding how others desire to integrate with your platform can help determine how you structure features and access points. You need to consider:

• At what points within the architecture stack will you allow access? Having well-defined access points within the architecture stack will help aid your partners in understanding how they need to approach platform integration.

• Are your customers looking to provide their own user interface and simply want to access a services layer? Or are they simply looking for providing a new skin on an existing platform application with simple and quick configuration to deal with branding and look-and-feel-related items? Having different levels of leverage will make your platform more appealing to a broader set of potential customers. It may also cause customer confusion about what they should leverage.

• Are there ways for you to leverage other internal or external platforms and avoid the ownership expenses (establish core capabilities versus adjacent capabilities)? The ability to leverage other platforms may create synergies and cost reductions that might not otherwise be achievable.

• Are there ways to leverage common assets to enable cleaner integrations? Is there a notion of modules or componentization that can make smaller units of the platform usable without having to consume the entire platform? The more that each of the capabilities has loose coupling with the other capabilities of the platform, the more orthogonal development and growth can occur. Otherwise, platform atrophy will being encroaching.

• Once decisions have been made to consolidate to a platform, how do you work toward consolidating applications? Consolidating hardware? Consolidating business models (which may not need to be done)? Consolidating capabilities? Developing a roadmap of how the consolidation will occur can help ease everyone’s concerns about the timing and help to identify issues that may be lurking.

• Is the type of integration more synchronous and transactional, or is it more batch and bulk oriented? How others intend to integrate with the system can have a dramatic impact on how the system scales. Make sure you understand this early on to ensure that the access you are providing into the platform will work well for them and for you.

• Does your system need to support mobile? If so, is it simply mobile web or does it require a native application? If it is native, what platforms does it need to support? Does it need to support offline mobile? Mobile concerns are higher up in the overall architectural stack and as a result can deal with more variability and changes as market needs change. The key is to clearly identify the location of key capabilities within the architectural stack and to understand the impacts of offline access to those capabilities.

I have seen instances where a platform started out with capabilities tightly integrated with specific business systems. This tight coupling of the business system and the platform enabled the users to get up and running quickly. Unfortunately, this tight coupling also caused the platform to be a major source of pain and delay for new applications that wanted to utilize the platform because they used different business systems.

In the end, be flexible and allow for flexibility in the different kinds of integrations that various businesses may want with the platform. The easier it is for them to leverage the platform, the faster the platform will become a success.

Scalability

For detailed information on scalability, please see Chapter 7, “Architectural Perspective.”

Security

For detailed information on security, please see Chapter 8, “Governance.”

Guiding Principles

Adhering to guiding principles can help establish a solid platform and extend its overall life.

Seek Exceptional Quality

The nature of leverage and reuse embodied within a platform drives the need for much higher levels of quality than would be necessary in a typical application. The wide variety of uses of the platform tends to stress it in many different dimensions, which results in the need for high-quality code and high-quality automated testing to ensure that not only are the new features solid, but no unintentional changes within the platform are introduced to those who are depending on its stability. In general, this makes development efforts for platform code a more expensive proposition and also highlights the need to focus on adding only those features that will be heavily leveraged.

Seek Operational Excellence

The operational needs of a platform are usually much more complex for a multitenant platform environment. Your ability to ensure that security, regulatory, and privacy concerns are addressed is table stakes in a platform environment. Take the time to purchase and develop the appropriate operational tools to

• Ensure that the platform operates with the insights necessary to help with growth planning

• Diagnose specific customer issues

• Detect security breaches

• Detect failures

• Alert when resources are approaching critical levels (such as storage full)

• Enable dynamic feature access and controls

Having the appropriate operational tools for the platform can help make dramatic growth both feasible and sustainable.

Seek Configurability over Hard Coding

In the development of platform code, it is easy to simply add in branching logic within the platform to choose which code to execute. Although this may be the “quick fix” to get something working, it adds brittleness to the overall code base. Take the time to learn how to enable the same behavior through external configuration, inversion of control, or dynamic operational controls.

If you do introduce technical debt, keep track of it and create stories to deal with it quickly. Technical debt can weigh down your future development velocity dramatically if you don’t stay on top of it.

Seek Leverageability

Platforms need to be developed in a manner that supports the broadest set of use cases and the greatest number of partners. Adding partner-specific code to a platform dilutes its overall value. One way to address this is to partner with customers for new feature requests and generalize what they are requesting. This will allow for the features to be more broadly applicable and enable the leverage opportunities that you are seeking for the platform.

Seek Redundant Architecture

Platforms should have multiple levels of redundancy built into them to enable scale, availability, and reliability. This includes having multiple physical locations, using clustering techniques, using caches with nearby persistence, backups, and other approaches that enable critical components to fail but allow the overall system to continue to function with minimal disruption. Redundancy generally favors a scaling-out approach versus a scaling-up approach.

Seek Linear Scalability

Platforms need to be able to scale linearly to ensure that the cost of adding new users does not become prohibitively expensive as the popularity of the platform grows. One of the best ways of ensuring this is to do regular scale testing with monitoring of key metrics within the system over time and ensure that scale is not degrading as new features are added to the system.

Avoid Platform Entanglement

Each change that is made to the platform can cause tighter coupling to occur within the platform. As changes are introduced, take the time to refactor the code base and the architecture to reflect the new directions of the business. A platform needs to change to grow and stay vital.

Avoid Platform Sprawl

It is easy during the midlife of a platform to want to say yes to all new development that shows up. Being willing to say no to adding things that don’t clearly align with the platform will help extend the overall life span and usefulness of the platform without diluting its central purpose.

Keep Upgrading to Current Technologies

One of the best ways to kill a platform is to minimize the investment in keeping the platform current with technology. Platforms are like any other system. You need to upgrade them every one and a half to five years as technologies go out of favor and are replaced with newer and better approaches and techniques. This should be done on a rolling basis, not as a big bang.

Summary

The road to platform development begins with

• Managing platform capabilities

• Defining the set of platform objectives

• Defining the set of platform capabilities

• Focusing on leverageable capabilities

• Developing a strong conceptual model

• Embracing APIs, configuration, and eventing as the keys to the platform

• Focusing on the platform ecosystem

• Knowing the platform users

• Understanding platform ownership

• Understanding platform management

• Driving platform development

• Acknowledging platform costs

• Managing platform quality

• Understanding platform integration

• Guiding the platform growth through principles

My experience has been that working on platforms from an architecture perspective is challenging and fun. The set of customer interactions and learning is a constant, which makes it exciting to go to work.

References

Benioff, Marc, and Carlye Adler. 2009. Behind the Cloud: The Untold Story of How Salesforce.com Went from Idea to Billion-Dollar Company and Revolutionized an Industry. Jossey-Bass.

Gharajedaghi, Jamshid. 2011. Systems Thinking: Managing Chaos and Complexity: A Platform for Designing Business Architecture, Third Edition. Morgan Kaufmann.

Godinez, Mario, Eberhard Hechler, Klaus Koenig, Steve Lockwood, Martin Oberhofer, and Michael Schroeck. 2010. The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight. IBM Press.

Leffingwell, Dean. 2011. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.

Levy, Steven. 2011. In the Plex: How Google Thinks, Works, and Shapes Our Lives. Simon & Schuster.

Meadows, Donella H. 2008. Thinking in Systems: A Primer. Chelsea Green Publishing.

Reynolds, Chris. 2009. Introduction to Business Architecture. Cengage Learning.

Ross, Jeanne W., and Peter Weill. 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press.

Simon, Phil, and Mitch Joel. 2011. The Age of the Platform: How Amazon, Apple, Facebook, and Google Have Redefined Business. Motion Publishing.