All organizations understand that large budgets and resources must be planned, tracked and reported against. The essential organization and management skills are commonly applied and are largely standardized across industries. There is little difference between the tools and methods from organization to organization. As projects became larger and more costly organizations adopted sophisticated Program Management Office (PMO) structures to track budgets, coordinate dependencies and communicate status. Significant resources and costs have been added and many organizations now have entire departments dedicated to program management. While critically important, Program Management alone has not solved the critical delivery challenge.

Both Program Management and Enterprise Architecture are essential organizational competencies, however for most organizations it difficult to assert that they are the source of the company’s competitive advantage. Despite significant investments in program management and enterprise architecture most technology initiatives remain challenged. According to the Standish Group, only 30% of IT projects deliver the required capability, on-time and within budget. This may even be inflated as the current Agile development has replaced capability-based budgeting with capacity-based allocations. Funding is no longer for a specific outcome, but rather a set cost allocation required to fund one or more Agile teams. What will be delivered, how it will be developed and when it will be production ready is up to the particular skills and performance of the assembled team.

How is it that after decades of technology development that organizations continue to struggle to consistently deliver the desired capability on time and within budget? One answer is Dimensional Complexity. Dimensional Complexity recognizes an organization’s aggregate complexity resulting from the dimensions of its operations. The primary dimensions include:

• Customer Segments
• Products & Services Offered
• Service & Operating Locations
• Supplier Network
• Countries
• Currencies
• Languages
• Delivery Channels
• Regulatory Bodies
• Applications
• Technology
• Cycle Times

A company serving a single customer segment, with one product, in one country, accepting one currency, enabled by a single application and technology stack would be a one-dimensional operation. Such a company has low dimensional complexity. It would be a relatively easy task to define business requirements, develop, test, deploy, operate, and support any needed automation. In order to grow, a company will expand along one or more dimensions to reach new markets perhaps with new products possibly new countries. This will typically cause the dimensional complexity to expand rapidly along multiple dimensions. What was once simple is now more complex. How complex is rooted in the variability that each expansion has across all the other dimensions. If a US company expands to offer its existing products in Canada, how does the new customer segment, new country, new currency, new regulations effect how products are priced, costs are allocated, the product is delivered and revenue accounted for.

It is essential to identify, understand, and design for the cross-domain impact caused by the business expansion and the resulting increase in dimensional complexity. It is the rapid increase in dimensional complexity created by vertical integration, consolidation, globalization and outsourcing that is the root cause for many IT program failures. It is common for IT teams to ignore the increased variability and in an effort to limit scope and simplify the solution, only account and build for the Happy Path or the Minimum Viable Product. But today few businesses operate in that simplified world. Instead companies compete in the reality of variability and they must adapt quickly to changing markets and new opportunities. On the other hand, successful organizations appreciate that agility is achieved by design, not by trial and error. These firms recognize that they must design for the natural variability and full scope of their business. With investments in operational design, they identity and design for the structural requirements of the solution, creating configurable products that account for future expansions along key dimensions.

Failing to identify, design and build for the natural variability and the structural characteristics of the business early in the program results in costly rework and project delays. And given the time and effort required to rework the solution already in progress, in the face of a prescribed sprint-based delivery plan, the remediation effort is prone to be a quick and dirty hard coded patch rather than a solution that will enable future extensibility. Short-term IT solutions often create long-term business constraints.

In many of these organizations, it is Business Architecture that is forgotten causing a gap between business needs and technology execution. Certainly, within an Agile Team the business product owner is charged with this responsibility, but without the organizing discipline of business architecture, their focus quickly turns to the specific stories. They often focus on the cosmetic features not the structural framework of the solutions. A team may start creating user screens before they have defined the full scope and structure of the data, particularly when it is not their area of expertise. Beyond capabilities, a business architecture blueprint provides framework for documenting, analyzing and communicated the business structure needed to support the dimensional complexity of the business. While Enterprise Architecture answers the question of how from a technology perspective, the Business Architecture answers the question of how from a business perspective. The components of a business architecture include:

• Business Process
• Information
• Organization
• Geographic
• Application
• Technology

While these are the same categories that an Enterprise Architect may address, the Business Architecture focuses on the business elements and structure and thereby provides critical insights informing the Enterprise Architecture. In the simplest terms, the Business Architecture identifies what needs to be configurable, the Enterprise Architecture defines how it will be configurable.

A company’s competitive advantage is rooted in the products and services it provides to the particular market and customer segment that it serves. It is the top business layer that is unique and specialized. In today’s global marketplace. These decisions then influence the Legal Structure required to service the chosen customer segment. Responding to the requirements created by this, an organization then must define its business processes, how the processes are distributed organizationally and geographically. From there this will influence the distribution of the various business processes across applications and data repositories. Finally, that all rests on a technical infrastructure with is highly standardized.

Business Architecture is the operational design discipline
that enables innovation and digital transformation.

The transformed organization that you are moving to does not yet exist. Therefore, it can’t be described, it must be prescribed. It must be designed using a multi-dimensional model-based design approach. In doing so, companies can unlock their competitive advantage enabled by the latest technical advancement.

The Business Architecture defines the structural requirements and the cross-domain relationships needed to serve the business and enable it to grow. Developing the organizations Business Architecture capability will complement the existing investment in Program Management and Enterprise Architecture and drive greater business and IT alignment and synergy. Equipped with a strong Business Architecture discipline, organizations will consistently deliver greater business value on time and within budget.

In an effort to drive operating efficiency, many organizations have embraced a process centric culture. While this has many benefits, one potential risk is that it can lead people to believe that data is a byproduct of a process. The primary focus is on the activities, sequence, timing and performance. The data consumed and created by the process becomes secondary.

Relationships between data subjects also reveal critical business rules that the automated process needs to support. For example, are all products or an order shipped together? Most businesses processes support more than one shipment per order. But if I wished to save on shipping costs, does my data structure support combining more than one order together? For many systems this is not enabled by the supporting structures and therefore there is not business function to combine orders for shipping. When it is done, it must be done manually outside of the supported automation resulting in higher costs.

Process architecture and information architecture stand separate yet are incredibly interdependent. When organizations elevate business information modeling as a parallel design activity alongside their business process design, the two disciplines complement and cross-validate each other. Organizations that take this approach are better able to:

• Identify and validate critical business rules
• Support business agility
• Capture data correctly at the source
• Ensure proper data governance
• Support data access controls
• Reduce data redundancy
• Improve data quality

Most business process limitations and many data quality problems are caused by data structure limitations. When these are addressed with a proper focus on information design, organizations can gain confidence in the results of the analytics platforms. Good data in yields data insights you can trust.

In the beginning the industry applied methodology, which brought standards, structure, and discipline to the software development process. Initially, moving from unstructured to structured approaches improved requirements definition and results. This was good! But over time, the focus shifted away from the business impact towards compliance with the methodology. The emphasis shifts to the rigid adherence to the process and personal certifications. As technology changed, so did our methodology. Object Oriented design was once heralded as the next greatest thing; but its design approach was too theoretical for the business user to understand and difficult to translate into business systems. Overtime what had become dubbed “waterfall development” fell out of favor and Rapid Application and Iterative Development then were to be the great answer. Organizations weren’t certain what iterative development was really, but what they did know is that it wasn’t waterfall. Many firms abandoned their good experience and practices, and retrained their organizations in Unified Modeling Language (UML). Many firms actually lost productivity as they retooled their organizations.

While iterative development allowed project teams to deliver a “series of small successes”, it was often at the expense of critical scope or increased total cost, when the second iteration required costly changes to the previously delivered components. Even Six Sigma, championed by Jack Welch of General Electric, has resulted in practitioners being more focused on being “black belt” certified than the business value of delivered solutions. The current affection with Agile shares the shame challenges. Today, internal auditors are charged to ensure compliance to the firm’s development methodology, but not compliance with desired business objectives. Another unfortunate attribute of most development methodologies is they tell you what to do, but not how to do it. There needs to be more emphasis on developing the design skills.

At the same time, technology innovations are frequently heralded as the “silver bullet” solution to our problems. A few examples include: relational databases, client server, end user computing, web technology, software as a service, business intelligence software, cloud-computing, and most recently Artificial Intelligence and Big Data. Client server technology allowed departmental solutions to be developed quickly and at a lower direct cost. However, they lacked the capability and controls of mainframe environments and resulted in a proliferation of hardware that had to be maintained and supported. Hardware, software, and database upgrades sapped limited dollars away from required new business capability. Per application development cost was reduced, in exchange for higher operational cost and increased risk. Billions of IT dollars are now being spent to remedy the problem.

Several years later, web technology allowed firms to reduce costs by having customers self-service by transacting on the web. But many organizations didn’t anticipate the operational implications and customer service costs to support this new business model. Data Security requires significant investment to prevent the loss of customer data.

Technical advances have allowed firms to do more, but all too often we have technology in search of a problems and expensive tools can be applied to simple problems. Organizations no longer have a stable and standardized technical environment, but a mass collection of often disparate and competing technologies. Cross technology integration costs continue to grow unchecked. More technology has translated into more complexity.

Having realized that methodology, technology, and program management alone were not going to provide the ultimate silver bullet solution, the industry shifted focus to unit labor costs and has, for the two decade, aggressively pursued offshoring and outsourcing as the great “silver bullet” solution. While it is true that firms can greatly reduce what they pay per hour in direct labor costs, there is little evidence that this has resulted a reduction in total cost or greater value. In many cases, the opposite is true as organizations struggle with cultural barriers, time-delay, miscommunication, inexperience, high turnover, and missed requirements. Efforts to mitigate these risks result in additional management oversight, cost, and delays.

The assumption that resources are fungible and that a recent college graduate in India is as productive as a seasoned professional locally is unrealistic. When results matter, experience matters. Companies are bearing the cost of training these resources and paying the price for their inexperienced in mistakes and rework. Some firms are finding that they no longer have the skills in-house to identify the mistake until it manifests itself in a system outage that disrupts their business. Often the costs to rectify such errors are prohibitive and the organization compensates for them with increased operational procedures and ongoing costs. As with the other disciplines, some costs are shifted away from low cost development resources to higher cost management as firms spend more time managing the relationship than the results. I have seen organizations become more focused on the utilization rates of their offshore software development factories than on the quality of the solution being delivered. Small teams of highly skilled resources will always outperform large less skilled teams. Fredrick Brooks wrote about this in 1975, in his book the Mythical Man Month. If you haven’t read it, you should.

During this same time, the scope of the business problem has become increasingly complex. We are no longer servicing the needs of a single business and automating existing departmental processes to increase efficiency. Businesses serve multiple customer segments, with multiple products, in multiple markets. Their operations are distributed globally and their business is more vertically and horizontally integrated than ever before. Business volume has grown exponentially. Add in that, the time a company has to service a customer has been reduced from several days to minutes in many cases.

And with decade’s worth of acquisitions and development, the technology environment is equally difficult to understand. So efforts that involve changes to the imbedded systems poses an increased risk to the business and requires extensive regression testing, another added cost.

Unfortunately for most companies, their technology capability is central to their ability to compete. It is the basis for the service they provide or it is central to their ability to manage the process. The problem is not going away. If anything, next year’s challenges will make the current situation seem comparatively simple.

To find the solution, we only need to turn to the office construction industry. If an organization plans to construct a new corporate headquarters, the first thing they do is find an experienced architect. An individual who understands how to design buildings, who understands how it will fit within the surrounding community, it’s current and future needs, the materials that will be used to build it, and what is structurally important. Most importantly, the find someone who has extensive experience and has designed similar buildings before.

The architect doesn’t gather requirements, they lead the owner through an architectural design process that asks and answers the essential design questions that provides all constituents an opportunity to understand and validate the proposed design. At this point, the architect is not concerned with, nor distracted by, what color the hallway on the third floor will be painted. Once the design plan is complete, then the resource plan can be development with confidence and firm cost estimates prepared. Equipped with a clear blueprint that includes a framing plan, electrical plan, plumbing plan, HVAC plan and site plan, the general contractor (program manager) can manage the various construction teams and successfully deliver within resource constraints.

Unfortunately, in most organizations, there is no functional equivalent to the architect. Many firms have Strategic Planning functions and nearly all firms now have a formal Project Management Office (PMO). But as for a Business Architecture Office (BAO), the function that sits between strategy and delivery, most firms come up empty. In these companies, business direction is handed from the strategy to the project manager, skipping the critical operational design step. Nearly all firms have enterprise and technical architects, people skilled in translating the business design into a technical design and expert in applying the proper technical solution. Unfortunately, they are starting with an incomplete operations design and fall prey to budget and schedule issues.

The business architect is the one striking at the root. The one charged with understanding the critical elements of the business strategy, charged with leading the operation design to figure out “how” the business will function based on the business strategy, and charged with delivering to the technology teams a operating model design that illustrates the process, organization, geographic, application, information, and technology components of the future business environment. Given a proper design, the program manager and technology teams can deliver against the original business strategy on time and on budget.