Why Architecture - practical steps in formulating a better architecture

For a number of years I (Ramesh Yerramsetti) was mildly frustrated working with solution architects, enterprise architects, application architects and Infrastructure architects on what I thought was a slow, defect ridden, and mostly conflicting approaches.  Consequently I have been distilling my experiences in form of a short blog which will help enterprise architects and CIOs alike on the approach for developing simply better enterprise architecture that has only one purpose - allow for a better applications landscape to serve customer needs and business objectives better.  This blog is not a replacement for standard texts in EA – nay it is an adjunct to help one become a better Enterprise Architect and work with solution, application, and Infrastructure Architects better. 

Why Architecture?

Businesses evolve and the rapid pace of innovation is shortening the cycle time a product has to be delivered.  Additionally, we must factor in the added complexities of the concomitant business design, production, fulfillment, and monetization of these new products, all adding layers of complexity.  For example by the time an IT organization learns about the need to setup a new distribution center, facilitate XML transactions between DCs and ERP systems, etc., it is usually too late in the cycle and time to deliver business needs is suddenly shorter.  Consequently, in non-mature organizations, we see a patchwork of applications where these “band aids” contribute to environmental brittleness and impede the ability of the organization to position themselves for further growth.  The project funding process and short lifecycle of modern projects especially in an Agile landscape is also contributing to the complexity of the Enterprise Architecture.  To add to the problem, there is rarely an alignment of functional requirements across business units, and even less often is there alignment with service level and other non-functional requirements across the business.

It is time to step back and consider alternate ways of approaching the EA problems.
Determining whether to implement an EA initiative begins with the following questions: 

·         Do you spend more than your industry peers on IT maintenance and support activities?

·         Are you slow to respond to business demands?  Does your business get constantly outwitted by competition in time to market? 

·         Do you sufficiently understand how to use and deploy new technologies such as cloud, mobile, BI, Collaboration, Change Management or Knowledge Management? 

·         Does your application portfolio contain a large number of custom applications, use numerous competing technologies, or make heavy use of specialized skills, including those skills only pertinent to your IT department?

·         Has your application portfolio been rationalized more than 5 years ago?

Case study 1: 

Case 1:  New projects impacting EA at a Food Service Company

A US-based food service company wants to move from a faxed orders scenario to B2B ordering. 

Challenge:
The challenge was to provide a solution to managing the supply chain initiatives in B2B and B2C space.   

Project Principles:

•          Process is King. Process Owners own the majority of the decision rights.
•          Start with an aggressive schedule and fit scope to schedule while delivering benefits.
•          Bundle capabilities into releases in order to enhance control and reduce the expense of redundant process teams, environment management and regression testing.
•          Meet business requirements to an “acceptable level.” Minimize customizations.
•          The Program is one team. 
·         Track performance via metrics.
•          Maintain focus on communications, training, and change management.

Approach:

The EA had to work with VPs from channel development, business units, the Project Managemetn Office (PMO), and Enterprise Solution Delivery.  The project used Agile concepts and techniques to enhance individual project delivery. 

Architecture Chosen:

Oracle iStore was chosen as the application, as the consideration was given to align with the existing Oracle eBS landscape.  As the project progressed, there was a realization that the current Citrix-based access model was grossly inadequate; there was a move to using Microsoft Unified Access Gateway and Web Application firewall from F5 systems.  Almost overnight there were three new applications introduced to the landscape.  In addition, there was a XML integration project being planned separately to connect the distribution center ERP system to the company’s Oracle EBS system.  New products were being introduced rapidly (almost 15 every quarter) with new fulfillment models.  There was also a need to grow geographically, with distribution centers (DCs)  being established in Canada and Europe Middle East & Asia(EMEA).  A new Vice President position was created for online sales, whose team was creating websites and applications.  All of these new applications were being added with one to one connectivity between each of these applications and ERP system.  There was no Integration center being planned, no EAI strategy, and no messaging framework or software system in place.  All of the projects were being run by the PMO as individual projects, without touch points among them. 

Results:

From a business perspective, this was a success.  There resulted an alignment between corp distribution team, regional distribution center and Central distribution center projects, B2B sites, XML interfaces between RDCs and finally Oracle EBS implementation.  This resulted in greater coordination, earlier identification of problems, greater speed to market of IT solutions, and greater alignment of IT solutions with the business. Other results include::

Two month project time shrinkage on B2B ordering site.

• Leveraging the DC interfaces.
• Integration of CRM on demand with B2B ordering platform which eliminated double keying of opportunities and orders. 
• Provision of UAG single sign on solution with Spanning WAF for greater security. 
• Template for bringing up DCs faster than previously done.

Conclusion:

Although the project was successful and has delivered tangible business benefits, it has resulted in:

• Introduction of additional elements from an architectural perspective.
• Increased governance costs (+15%).
• Need for new skills in the landscape (Java, JSP)
• Relatively new applications with unknown support structure needs
• No attention given to EOL support for Oracle EBS version
• No consideration given to emerging products from the Oracle suite in the online ordering space, such as Oracle Dynamo ATG Dynamo acquisition.

Case study 2:

New business models impacting EA at a Large US Software Company

A US-based software company was creating a new online model to connect with large account resellers and other partners. 

 

Challenge:

Microsoft OEM has traditionally utilized a paper method to prove software authenticity, called the Certificate of Authenticity (COA), which is affixed to the base of the machine’s chassis.  In order to move away from dependencies on the paper COA, ensure Supply Chain agility, create a foundation for revenue opportunities, increase OEM value by providing the end user with a Genuine Windows experience, and reduce piracy vectors, Microsoft created a global project to associate software and service entitlements to hardware, ultimately enabling opportunities across the OEM Ecosystem. 

Goals:

·         Overall 3 hour E2E order to fulfillment.

·         Decreasing key generation cycle time to align with 3hr target.

·         Scale E2E fulfillment architecture to support future demand.

·         Improvements to forecasting and planning system.

 

Solution

The team’s efforts in the development of the product and operations and solution delivery strategies were aimed at an end-to-end solution for the Digital Supply Chain involving the Agreement to Cash cycle.  The partner readiness engagement activity covered over 144 OEMs/ODMs worldwide, while the solution delivery engagement included SAP ECC, SAP OER, BI,  custom license key generation, key reporting/activation, distribution systems and a variety of systems integrations.

The final solution was a website, and behind the scenes is a whole set of systems for License Key generation, Key provisioning, License management, Key expiry, and other lifecycle elements.  There was a backend SAP ECC ERP system that tracked purchase orders, created sales orders, performed credit checks, and established the complete digital supply chain.   All data went through a central Integration center, and all application use one-to-one connections with ERP.  Although in this case there was a central location for all transactions, there were still one-to-one connections and there was no coherent EAI strategy. 

Results:               

·         High level of organizational integration within and across strategy, operations, solution delivery, and partner readiness. 

·         Delivery of an integrated system with Order UI, Order web service, Fulfillment web service, key generation and distribution systems, and key reporting/activation meeting SLAs in the test environment. 

·         Partner outreach to over 144 OEM/ODMs with effective communications and provisioning of manufacturing shop-floor systems.

 

Conclusion:

Although the project was successful and has delivered tangible business benefits, it has resulted in:

·         Introduction of additional elements from an architectural perspective.  

·         No attention given to the overall company IT landscape,just the divisional landscape. This may result in conflicting elements or duplication of efforts in some other division. 

·         Increased governance costs (+10%). 

·         Opened internal applications such as SAP ECC and mission critical key generation systems to the outside world. 

·         Need for new skills in the landscape (New message bus). 

·         Relatively new applications with unknown support structure needs.

 

ROI calculations

It is always challenging to specifically attribute any business value or cost savings to any one initiative.  However, it is a necessary and required exercise.  ROI calculations are reviewed carefully by approval committees, steering committees, and finance teams. 

Costs:

Cost of EA team:  Solution Architects, Infrastructure Architects, Application Architects, Directors.

Cost of perceived (sometimes reality) change in speed of delivery due to “Architecture bureaucracy.”

Cost of additional elements: infrastructure, applications, access, security.

 

Business Value:

·         The value to business agility, consistency, scalability, dexterity, compliance to regulation or opportunities from deregulation.

·         Ability to manage change.

·         Reusability of system components across project and for projected business expansion.

·         Better access and understanding by all employees of the current and projected capabilities and data flows. This assumes that Enterprise Architecture is communicated with all employees.

·         Faster understanding of the impact of any specific change as opposed to protracted analysis

·         Increased employee morale due to better system and lessening of systems anxiety. 

 

The most complete model thus far is based on Real Options Analysis and the cost model is as follows:

N(d1 )× Benefits − N(d2 )×Costs × e−Rate×Years

d1 = [ln(Benefits ÷ Costs) + (Rate + 0.5 × Risk2) × Years] ÷ Risk × √ Years

d2 = d1 − Risk × √ Years

Once you establish ROI as the success factor, you begin by operationalizing a core set of metrics and measure the payback.  

Governance Models

EA governance needs to be embedded into the organizational DNA.   How to embed EA Governance into your organization is out of the scope of this book, but the cost of that governance is certainly within our scope.

Enterprise Architecture is, at the end of the day, about using money wisely: either reducing internal costs or making it easier to make more money using faster and better solutions.

The cost of governing consists of:

·         Hardware.

·         Software, either licenses or accrued development costs.

·         Services, communications, or cloud costs.

·         Manpower to keep a solution up and running, commonly referred to as Product Lifecycle Management.

If you have an enterprise-wide solution, such as an advanced ERP system like SAP, you likely have a ton of costs in the first categories. But for a majority of solutions that are supporting parts of your company, you will see that the last bullet is often the major cost. Much of this cost, however, is hidden.

Whenever you have a solution that is not consistent with your EA you usually have a solution that is much more expensive than you realize. This is because a solution that does not comply with the way the EA says a solution should be delivered will entail secondary costs.  The solution will still consume the infrastructure budget and therefore does not hit the product or system owner as it should.

The cost of maintaining a competence base is very high, so the fewer of these you have, the lower your costs will be.  Any solution that is based on a competence that is not common will be extremely expensive to govern. For example, having only one application that uses a MySQL database or only one solution that runs on a Linux server will be very expensive.

Both of these cases will require you to keep a number of people with that specific competency, which is costly. This is not, it should be noted, a dictation on which platform is best; consistency in your EA is integral, regardless of platform choice.  If you implement a budget where you allow the solutions that have this one-off architecture carry the full burden of the actual costs, you will get a true picture of your costs. This will in turn enable you to do better ROI calculations.
The other side of the coin is that is a lot of money to be made out of killing of the last of its breed. Most organizations would benefit from having a “Reduce Infrastructure Project” with the goal of shutting down servers.

Practical steps in EA formulation

A.      Business Environmental Scanning

This involves looking at the company’s business drivers and competition.  Working with the VP level individuals of respective business units and channels, the EA needs to understand where the business is headed in the next three years.  This informs design of the Enterprise Architecture design drivers.

B.      Technology Environmental Scanning

The EA needs to stay abreast of upcoming changes.  The technology field is riddled with constant change: the arrival of Java and object orientation both changed the landscape dramatically.   

C.      Creating an Inventory of all applications

Create an inventory of all applications and architecture diagrams, as well as all the connections and integration between them.  Survey current business teams to understand challenges in cycle time and the  issues reported at enterprise help desk.  Develop a pattern and a story of what is happening. 

For example:

The integration center is a bottleneck – takes too long to process a transaction.

The development team has adopted Agile, yet the solutions do not meet the business need.

The sales ordering tool works well for some customers,but not for others.

D.      Creating a Project requests pipeline

A project requests pipeline gives a very good understanding of the road the business wants to chart.  It  gives you insights into what the organization deems important via the prioritization process.  It also gives insight into the amount of duplication, the proliferation of standards, and competing technologies that will be proposed to be used.  Also mapping the projects in the pipeline to existing landscape will give insight into how much deviation is likely from EA roadmap. 

E.       Capabilities to Tool Mapping

The following diagram shows that the next step is to map the current or planned capabilities to tools/projects.

F.       Regulatory and Corporate Policy Needs

Each industry vertical – be it healthcare, hi tech, or manufacturing – brings unique privacy, security, and compliance needs.  Understanding, anticipating, and documenting these needs will go a long way in clearly formulating enterprise architecture.

G.     Develop a Consistent set of Principles

The importance of having a consistent set of principles cannot be overstated.  Fortunately, you do not need to start from scratch.  Several corporations, such as Microsoft, have developed recommendations on Architectural Patterns and Styles.  Microsoft’s recommendations are available here:  http://msdn.microsoft.com/en-us/library/ee658117.aspx.  Once you pick an architectural style, stay consistent.  It will save you a lot of headache down the road.  Also align the reference architectures provided by application, infrastructure and solution vendors.  Every vendor views the solution in a limited sense.

H.      Old Architecture vs. New Architecture

Do not try to change all of the corporate architecture all at once.  Start small as new projects arrive, attempt integration with existing Architecture.  Aim for the new architecture to follow all the principles developed in the previous step.  For example, if new systems are introduced in a landscape,  apply a consistent set of architecture principles to accommodate the new features.  As old applications are due for retirement, the old architecture will be gradually replaced by the new.

For example, when a US-based Hi-tech company wanted to move to an online ordering solution, there were two other distribution center and geographical expansion projects in other divisions being planned.  Due to lack of inter-divisional communication, the projects were duplicated.  The consequence was that additional technologies were introduced in the landscape, which only EA complexity while not adding any incremental value.  A better  approach would be to collaborate among these projects and decide which new technology artifacts need to be introduced in the landscape.  Then have a plan for absorbing the existing applications or their replacement (when they are retired) into this rationalized architecture across the corporation.

Budgeting for Architecture

In our experience as consultants, we find that the budgeting process happens for prioritized projects, and there is sometimes little appetite to fund Enterprise Architecture development and execution projects.  When EA activities and downstream solution section activities are done, they are often done as a part of the project itself, which increases project costs and decreases delivery speed.  The key items to address are:

·         Who owns the budget - is it jointly between EA teams and application/solution teams? 

·         How is the Infrastructure team organized vis a vis the EA team?

·         Will the EA component precede the application/solution component?

Maintenance of Enterprise Architecture

Enterprise Architecture is a living artifact.  It requires establishment of business and system compliance with the organization.  In order to be successful, there needs to be a closed loop continuous assessment of the architecture as it is implemented and then enforcement of compliance with the EA artifacts on an ongoing basis.  There needs to be an Enterprise Architect dedicated to the purpose of gleaning the business needs and project artifacts to maintain the EA artifacts. 

A Change Control process needs to be set up  to review proposals and identify impact of the proposals.  Change should be systematic and aligned with future goals of the organization.  The cost of change should be vetted against the ROI calculations. 

Every project manager is trying his best to maximize project success.  The EA has to understand and influence how each project can meaningfully impact the enterprise architecture without creating situations where it becomes difficult to retract from decisions made.  For example choosing between two programming languages - .net or Java or choosing both in the landscape.  Off the shelf (COTS) vs. custom programs and the proportion of their use has a lasting influence in the rigidity of the architecture that results.