The 4 Phases of Successful Bidding Reply

ICT deals are unlike other technical deals. Whilst engineering deals may be ‘complicated’ with their detailed technical details, ICT deals are often exponentially more ‘complex’ because they blend loose business concepts with technical specifications. Technical success is pegged to business benefits or unknown end states at the end of lengthy business transformations based on multiple increments of capability. For this reason the standard Colour Phases of bid development do not adequately support large, complex ICT deals. Robust process is a must in order to ensure adequate cross-functional collaboration across large, dispersed organisations. However, tech deals need to evolve through iterative stages of architectural development. The diagram below sets out a colour phased development lifecycle for large and complex tech deals. In this way, they get the process to manage the organisational governance as well as the architectural focus necessary to develop a winning value proposition.

THE ISSUE

The issue is never designing the solution it is unpicking it. Tech deals are not only complex they are aggregations of complexity: security systems, infrastructure, applications, business rules, benefits, integration – it all develops in isolation and it all has its own logic and its own costings and commercial parameters. It does, however, all work together. So, when it comes to the end of the bid and the team have to reduce costs in order to hit their estimated price-to-win it is somewhat akin to playing a giant game of “Kerplunk“. Straw by straw the architecture is unpicked and all the stakeholders around the metaphorical table just hold their breath and hope that not all the marbles fall down. If they don’t it is pure luck.

Technical ICT architectures are not like normal technical engineering projects or other capital works. The customer is not building an independent means of production. ICT (less robotic systems, i.e. embedded technology) is an integral and entwined part of business capability. It is inextricably linked to the business. If the dots are not all joined at the outset of the bid then when it comes to reducing costs at the end, the executives will strip down random parts of the technical solution which is usually the foundation of the value proposition. What will be left is a patchy solution that has obvious structural weaknesses (to the intelligent customer).

THE PROBLEM

The problem is how to design elegant and sophisticated architectural solutions within cost, commercial and time parameters. The individual system components will be designed in splendid isolation with a variety of assumptions and guesses. The entire solution, however, needs to be designed, costed, stress-tested and reviewed within tight timeframes and against aggressive price points. In order to lead a large and disparate (often virtual) team to achieve these goals will take a robust process and a strong personality exerting herculean effort. The crux of the matter is how to manage varied personalities through a convoluted development process without stifling the elegance of the design yet still manage to corral such strong temperaments through tight review gates.

THE SOLUTION

The solution is a blend of both the traditional colour-phased bid structure and the complexities of the architectural development process. Together it might be referred to as Colour-Phased Architecture. In this way the bid team are cognisant and appreciative of the subtleties and complexities of the architectural design process and the executive get a strong process which even the strictest governance may rely on.

THE PROCESS

Adapting Krutchen’s 4+1 Views the architecture is developed through 5 critical structures:

  • Use Cases. The Customer narratives and scenarios are developed to produce and update the various iterations of the architectural solution.
  • Architecture. The solution should develop through 4 iterations:
    • Logical – This will ensure that it is anchored by the strategy and accurately reflects it.
    • Physical – This is where specific solutions are developed and the tighter parameters are loaded.
    • Transition – This addresses the specific issues around the deployment, transition and change management issues for the customer.
    • Transformation – The vendor should make the majority of the margin during this phase and so much of the strategy, modelling should focus on the incremental capability uplifts. This is where the primary benefits realisation management should focus.

Architectural Development

The architecture of the solution is defined by a careful communication between elements. The interaction between the structural colour-phases and the functional solution development supports this in two ways: (i) the Use Cases inform the design of the solution, and (ii) the phases inform the development of the solution. Initially, the customer use cases determine solution design. The solution must be derived from a desire to solve the customer’s problem. A list of requirements is essential and usefully but may only result in a patchwork quilt of technical components and business benefits. The logical solution will then be molded and developed using the vendor strategy and broad parameters.

The physical solution along with more detailed attention to the Transition and Transformation stages is then pushed through another 3 phases of development. In this way, the team ensures that the architecture is not only technically comprehensive but that it is a sensible, well costed solution that will meet the customer’s needs well into the future.

Process Colour-Phases

The colour phases are essential because without them the architectural development process would just spiral out of control. The colour phases ensure:

  • that the development of the solution occurs within a structured governance framework,
  • that there is cross-functional collaboration between the technical silos and the commercial support, and
  • that the progress of development is measurable and communicable to the non-technical executive.

To that extent there are 4 essential phases to ensure that the technical solution does not exist in splendid isolation but is a well costed, commercially sensible plan to make money by delivering something which plays to the vendor’s strengths whilst delivering something of real value to the customer. In order to do that the process must ensure it develops:

  1. Strategy. The strategy must be developed from the outset. Architecture is not strategy. Without strategy there is nothing to anchor the technical development with and nor is there anything to prod and cajole business partners with.
  2. Architecture. Solution development is only part of the process. As with any design process, the artistic talents and temperaments of the team must be constrained and focused.
  3. Commercials. The commercials have to be right. No matter how elegant or sophisticated the solution, unless it works commercially it will not be signed off.
  4. Viability & Review. The solution must be able to be reviewed internally by peers and colleagues. It must exist as a coherent body of documents (which will be pulled together into the bid document). The team must be able to prove that the solution will work over the long term and exist as a part of the customer’s enterprise architecture.

There is both art and science in the design, development and management of large and complex bids. Bids team not only require the gravitas of deep technical ability but also leadership and communication skills. Without these the solution will not be balanced but rather a mess of technical solutions competing to over-deliver functionality. There is no easy way to navigate the issue but a colour-phased process of architectural development blends the best of both worlds into a practical and deliverable lifecycle.

Figure 1 – A colour-phased lifecycle for technical bids.

CONTRACTING FOR CAPABILITY: the future of outsourcing Reply

Outsourcing only works for vendors. It does not work for customers. Revenue curves for vendors show a slight increase since 2008 for global outsourcing growth but the picture is less clear for customers. When looking at the economic-value-added (EVA) for businesses before and after outsourcing deals most show a nett decrease, which is to say only that they are weaker after the deal but not necessarily because of it.

The reasons are myriad however there are a few standard reasons:

  1. outsourcing is usually part of cost reduction activities of panicking organisations.
  2. there is usually a nett decrease in headcount which wipes out the value-added aspects of reduced costs.
  3. the customer’s SG&A costs usually rise due to the increased management activity needed in finding and using information.

Due to these reasons there is a feeling in the market that outsourcing does not work despite the claims of vendors. Therefore, vendors have increasingly (certainly since 2007) seen themselves fighting for an ever shrinking slice of the economic pie. The greatest sources of competitive advantage have been reputations and economies of scale. All, however, have been scrambling for a differentiator that does not involve reducing their own profits.

MIDDLE-OFFICE OUTSOURCING

One large UK outsourcing outfit saw the writing on the wall. It felt that it would not be able to compete with the lower labour (and similar outputs) of India-based companies. It rationalised that eventually it would be squeezed out of the back-office (i.e. highly standardised financial processes) outsourcing and infrastructure hosting markets. It would, it rationalised, need to move into middle-office outsourcing. Front-office outsourcing, on the other hand, is largely fictional as it encompasses the customer-facing aspects of a business which is where the key differentiators are.

Middle-office outsourcing (such as a council planning approvals process) is unique because it involves less repetitive processes and sometimes ad hoc activities.  Success here is necessarily predicated on a flexible IT infrastructures (often service-based, i.e. SOA) and a sophisticated management which is able to choreograph technology-based processes and services.

COMMERCIAL CAPABILITIES

Being able to outsource the middle-office involves positioning the vendor into a customer’s capability. A capability is the ensemble of systems, processes, people and information/data necessary to do something. In business terms this means all the stuff that is necessary to perform a process. Technically, capabilities are specifications of an enterprise’s Value Chain, so in broad terms a business will have about 20-ish key capabilities. All capabilities are, necessarily, linked. The closer one gets to the front-office the more these capabilities need to (i) be performed and supported in real-time, and (ii) they also need to consume information and services from elsewhere in the business. For instance, in our planning approvals process example the vendor will have to (a) log approvals in real-time, (b) consume up to date information on structures and utilities, as well as (c) access information on business rules (i.e. council policy, governance, law etc). As with any outsourcing activity, more narrowly focused personnel on lower pay bands are used to perform tasks more ably supported by better technology. All these aspects not only add to the complexity (and therefore the price) but also to the potential liability. When offering low pay band workers to crank the handle on repetitive processes liability is something a vendor wishes assiduously to avoid.

DEFENCE CAPABILITIES

Capability is a term much abused but little understood in Defence circles. Much of this is because Defence does not use a standard value chain. Although there is a business model for most western Defence communities (Inform > Project > Operate etc) there is no need for a value chain because there is (i) no need to differentiate, and (ii) planning and financing is based on the use of ‘unlimited’ funds to confront external threats (i.e. Treasury tends to play second fiddle during war).

The military user will often class themselves as a ‘special’ customer. The defence industrial complex is a special environment for the simple reason that they are providing equipment which – if the enemy is successful – is useless to the customer by the time it enters service. Unlike the commercial enterprise, where such a situation would mean they lost some competitive advantage/margin, in the military such a situation is untenable. The purpose of a military capability is therefore to change quickly and radically over time in line with the threat. Corporate structures are notoriously incapable of maintaining the same tempo of development, even with lavish operational funding. The purpose of ‘Contracting for Capability’ is to solve the problem of commercial-lag whilst still providing a cost effective and commercially robust means of contracting.

THE CONTRACT: A COMPLEX ADAPTIVE SYSTEM

This is possible by viewing the capability environment as a complex evolving system which requires the commercial deal to be a complex adaptive system. This is not new to the law. Building and construction deals have been taking this approach for years and German franchising law has excellent precedents showing how risk may be judicially assessed throughout a large, distributed network of commercial entities – for a common purpose or effect.

Figure 1 – Shows how commercial deals fail to keep pace with and support military capabilities.

‘ROLES’ – The Key to Capability

The key difference between commercial and military capability is that in the military environment the vendor cannot own the people. In business, the customer will transfer the roles over to the vendor. In the military equivalents of the middle and front offices (i.e. front line and forward echelons) the vendor will never own the people. Soldiers will always perform critical tasks. This will remain a constant for some time to come as soldiers do not say (i) “the computer isn’t working”, or (ii) “do I get overtime?” etc.

Although a vendor cannot own the people it can own the ‘Role’ or the role specification, i.e. the processes, information and systems that a role uses. In this way, a vendor can support the core functions of a role without hindering the actual person’s ability to go outside the boundaries of that specification to ensure that something is done. For instance, a aeromedical evacuation must take place regardless of whether a computer is not working. The airman performing the tasking may have at their disposal a sophisticated orchestration of processes based on flight availabilities, supporting gunships, bed availability and surgeons on duty. However, if the network is down it is unacceptable to let a soldier die just because the computers are not working. That airman must now use their deep knowledge to work the radios and help save a life. On the other hand the military is largely incapable (and unwilling) to integrate the vast array of ICT necessary to develop the initial systems.

Figure 2 – ‘Contracting for Capability’ using commercial communities to support capability clusters.

COMPLEX CAPABILITY

The example of an aeromed evacuation is somewhat simplistic. The example above refers to the Deep Target Attack capability. This capability may be performed by submarine/ship-launched missile strike, aircraft or even Special Forces. The choice is a military judgement. In the case of a submarine launched method the enemy will try to prevent this through anti-submarine naval activity (ASW). The submarine needs to close to striking distance, reach launch depth and then withdraw safely. How is it possible to support such a process which involves very long and expensive R&D lead times, long into-service acceptance testing, new training and tight export controls as well as restrictions on the use and sharing of sensitive information?

The trick is to incentivise the commercial community to do some of the thinking for the military. Instead of having to wade through the commercial treacle of Defence procurement the following steps could be taken:

  1. Base contracts on Capability Increments. In this way, the vendor is obliged to keep pace with threat evolution and the development of capabilities.
  2. Outsource the Role Specification. This will ensure that the military community is forced to involve its commercial delivery partners (without being hamstrung by systems).
  3. Create Commercial Communities around the support to certain key systems/clusters of technology. This is similar to German franchise systems whereby all parties are legally obliged to discharge their contractual obligations in line with a common purpose. This will circumvent the horrific impasses usually experienced in alliance contracts.

Contracting For Capability is a logically sensible concept which simply builds upon the work already achieved in the Enterprise Architecture community (especially MoDAF, MoDEM and the IDEAS Group). It is not overly complex nor is it a step too far. Once again, the real question is whether Defence and industry have the sophistication and diligence to complete the task.

Enterprise Architecture: Is there any such thing? 3

I should preface this post by saying that I am a huge fan of enterprise architecture and have been for some time.  However, I posit that there is simply no evidence that enterprise architecture actually exists or will ever exist.

If EA were working or was economically viable we could have expected a decline in the global outsourcing market as businesses sought to integrate and consolidate applications along an enterprise metamodel.  However, this work predicates a level of control and ownership which is not consistent with applications/business process outsourcing.

Global Outsourcing Market

Definitions of EA aside, it seems clear to me that the economic benefits of EA simply cannot compete with the economic benefits of outsourcing.  In order to turn the tide, my personal opinion is that EAs need to be able to architect from the financial instead of the minutiae of the technical.  Stop trying to solve technical problems and start trying to solve business problems.  More importanlty – in line with the ‘E’ in enterprise – be able to cut through the petty bureaucracies and fiefdoms of middle management and begin to define business problems by calibrating financial statements with technical information.  In other words, how can technical architects analyse adverse financial variances on the monthly balance sheet and turn them into changes in the technical development or delivery?  What is the technical implication of a month-on-month 17.5% adverse variance on Indirect Labour?  Until these figures become the mainstay of an Enterprise Architect’s work then EA will never be able to compete with the simple value proposition of outsourcing, i.e. “it’s not working! give it to an expert.”

More importantly, in virtually all businesses (i.e. non-tech businesses) the company is defined by accountants and sales people.  Operations comes in close second and IT is so far at the back of the corporate parade that it can’t even hear the marching band play.  In order for Enterprise Architecture to morph into something useful – and something closer to what I imagine Zachmann imagined – it will need to deal with enterprise engineering.  This is the difference between systems engineering and Engineering Systems, i.e. the engineering of information between the various systems/functions in the business.  What is the atomic meaning of a cost variance in IT terms? 

Until EA/EE can truly grasp the complexities of the enterprise it will only ever be IT window-dressing.  In the meantime, I hope I’m wrong.

EA as Strategic Planning: I’m Still Not Convinced Reply

Business and TechnologyA recent blog entitled: “EA is Strategic Planning” highlights a sentiment by many enterprise architects (a widely abused moniker) that what they are doing is new, ingenious and necessary.  I’m still not convinced.  Whilst one cannot decry the skills, expertise, knowledge and ability of many enterprise architects I am yet to see a cogent argument that what they do is either cost effective or necessary.

Heresy?  Hardly.

The enterprise has done remarkably well since the Dutch East India Company was granted its royal license in 1600.  The rise of the  enterprise has not abated and diversified companies such as Du Pont and ITT have shown that complexity and size are no obstacle to good, valuable shareholder growth. 

IS EA JUST GOOD IT?

I am in two minds:  (i) EA has certainly helped the IT community with complexity by bringing a portfolio view ICT programs, but(ii) EA has added no significant value to a listed company (beyond just good sense, well delivered IT programs) or reduced its risk to such an extent that would warrant dedicated EA. 

EA has likely been the product of a traditional lack of the requisite skills to translate the social value of collaborative software into corporate monetary value.  It is worth noting that embedded systems (such as robotics) and operational systems (systems that a given corporation simply cannot perform its operations without) are not included in this assessment as their value to the business can be calculated in a simple NPV assessment of projects, i.e. the system will directly result in higher discounted cash flows.  That this should be the job of a programmer is nonsense.  That large commercial enterprises are only beginning to adopt social media systems (which people have been using for years) highlights the general inability of enterprises to grasp the financial value of subtle and complex ICT.

SO WHAT DOES EA OFFER?

Enterprise architecture is not strategic planning.  As much as I like David Robertson’s book “Enterprise Architecture as Strategy”, it is farcical to suggest that the structure of an organisation should either come first or drive (other than the broad parameters)  the functional design of the business model.  If EA is to deliver value to the organisation then it must reach beyond large, complex IT.  To add real value it must be the the function which is capable of reaching across the business siloes to solve the problems which the corporation does not even yet know it has.

ENTERPRISE ARCHITECTURE AS A SEPARATE DISCIPLINE

Enterprise architecture must grow out of its humble ICT beginnings if it is to have the boardroom caché and intellectual gravitas necessary to drive strategy.  EA must develop beyond it systems engineering fundamentals and extend its validity into the statistical relationships between technology structures, information performance and shareholder return.  Only in this way will EA be able to communicate the financial return which subtle and complex MIS systems can add to a company.  Whatever enterprise architects believe they can do they will not get the opportunity to display their value, beyond simple tenders, unless they can convince the finance function.

Measuring Risk in Logical Processes Reply

logical-architecture.-wire-diagram.pngLogical architecture is valuable in the design of large systems for 2 key reasons:  (i)  it helps developers instantiate the softer concepts and  more social aspects of large systems, and (ii) it provides another review-gate to iron out design flaws before proceeding to the physical system.  Military systems provide good examples of the value of logical architecture.  Many Defence systems are so complex that they are never developed at all.  If they are at all then they are often broken down into such small components that the integration can become unmanageable.  Joint Effects Targeting, counter-IED exploitation, systems to fuse operational and intelligence and the nuclear firing chain are all areas which have enormous social input so that the development of a logical architecture is paramount.

Unless a person has a pedigree in military systems logical architecture is, usually, the least understood/used part of the design process.  Certainly in Agile environments or any area requiring rapid applications development where the application is fixed (portals, billing systems, SAP etc) then logical architecture design is nugatory.

In this blog we look at logical process design but the method is equally applicable to the entire logical design phase.

BENEFITS OF LOGICAL ARCHITECTURE

When designing processes, however, logical architecture is an invaluable tool in measuring, assessing and comparing risk before moving to the more expensive technical design & implementation phases.  Because logical designs can be created, compared and assessed, quickly,  they become an excellent technical/commercial appraisal tool.   Cross-functional teams of executives and architects can collaborate on logical designs before a GO/NO-GO investment decision and thereby create 3 major benefits:

  • Reduce the time of the physical design cycle.
  • Increase executive involvement and the effect of executive steering on designs.
  • Significantly reduce the risk in physical designs.

PROCESS VALUE

The Value of a Process

There is a way of viewing, and thereby measuring risk in logical processes.  Ultimately, the value of a process is its cost divided by its risk.  So, a process which has a total cost of $100,000 and a 60% chance of success has a nominal value (not “worth” or “price”) of $60,000.  Which is to say that on average the business will realise only 60% of its value.  This is roughly the same as saying that, on average, for each $100k in earnings, the firm will spend $40k on faults.  Whether the value indicator is dollars or white elephants does not matter, so long as it is applied consistently over the choices.  This simple measuring mechanism allows senior executives to engage in the design process and forces architects to help assign costs to difficult design components.

COSTS & CONCEPTS

The difficulty is in ascribing costs to concepts.  In order to do this the team must first instantiate the concepts win some form of logical structure, such as a software system or a management committee/team.  The team then ascribes an industry benchmark cost to this structure, accounting for uncertainty.  Uncertainty is important because the benchmark cost will not represent the actual cost exactly (in fact the benchmark cost should represent the 50% CI cost).  So, when it comes to determining the probability it is vital to use the experts to come up with what the construct could cost (as little as and as much as).

PROCESS RISK

The difficulty with measuring logical architectures is in measuring concepts.  Concepts usually have no value and no standard means of comparing them.  In short, (i) assemble a small, cross-functional team of experts, (ii) ascribe costs (with uncertainty) to the concepts, apply a risk equation, and then (iii) simulate.  One possible equation is:

Logical Risk Equation - An equation for measuring process risk in logical architectures.

Where:

  • R is the overall risk.
  • P is the probability of an adverse event occurring in the process.
  • Ct is the criticality of the location of the event, in the process.
  • is the likely time it will take to notice the manifestation of the risk (i.e. feedback mechanisms).
  • Cy is the availability of a contingency plan which is both close and effective to the point of the problem, in the process, and
  • Sl is the likelihood of success that the process will be fixed and achieve an acceptable outcome.
  • 100 simply makes it easier for the team to see differences between scores.

In this equation, we determine the overall risk of the process.  It does not have to be perfect but rather it just needs to be applied consistently and account for the major variables.  If applied rigorously and evenly, measuring risk in logical architectures has the ability to reduce the design cycle, increase the certainty of the choice, build better stakeholder buy-in and significantly reduce the risk in the physical solution.

Wall Street Beat? The Fiction of 2013 IT Spending Forecasts Reply

Wall Street Beat: 2013 IT Spending Forecasts Look Upbeat.

If this is the case then an organisation with a $USD 100m IT spend is set to increase their capex by $3.3m this year and $6.1m next year.  This represents almost $10m increase in capex in the next 2 years.

I am not sure where they get these figures from?

technology spending. tech rebound. mckinsey chart

If we assume the standard wisdom that economies traditionally take 2 years to recover from recession and a further 2 years to return to trend growth then it will be 2017 before IT budgets hit 3.4% growth.  Given the savage cuts in IT budgets after the recent recession(s) I think these figures are conservative.  A further factor to consider is that the ICT industry is so highly segmented that generalised growth is meaningless.

Looking at the finances of the tech rebound of 2003/3 (shown above in the Mckinsey & Co chart) we can see that – at the high end – IT capex of $73m accounts for 12% of the overall budget.  At this rate, 6% growth equals a $36.5% growth in capex by 2015.

This is, of course,  nonsense.  The moral of the story is:  don’t look at reports of astonishing growth in the tech sector.  Research has shown that the ICT sector is made up of so many tiny segments that even McKinsey’s figures are to be viewed with caution.

In summ, the burst of the 2001 tech bubble saw IT budgets plummet roughly 70%.  There are no reliable current fugures as to the general sum of cost cuts per sector in ICT budgets.  However, if we count on 10-25% overall budget reductions then it will be well beyond 2017 before we see budgets returning to pre-2008 in real terms. If anything is certain, however, tech always surprises.

 

BUSINESS PROCESS FAILURES: the importance of logical architectures Reply

business process risk. chart

In a recent 2012 survey by McKinsey & Co, IT executives noted that their top priorities were ‘improving the effectiveness and efficiency of business processes’.   One of the critical failings of IT, however, is to implement effective and efficient business process architectures in the first place.  The IT priorities to the left only serve to highlight what we already know:  that IT service companies implement processes badly.

Why?

Whether through a failing of Requirements or Integration (or both), IT service companies often implement inappropriate business process architectures and then spend the first 6 to 12 months fixing them.  This is why those companies ask for a 6 month service-credit holiday.  It is also the same reason those companies differentiate between Transition and Transformation.  The former is where they implement their cost model but the latter is where they implement their revenue model.

The failing is not within the design of the technical architecture.  Very few senior executives report that failed projects lacked the technical expertise.  Likewise, project management is usually excellent.  Requirements, too, are not usually the problem with business process implementations as most commercial systems implement standardised Level 1 or 2 business processes very well.

Logical Archtiectures instantiate the subtleties and complexities of social systems which the software must implement

The first failing in the development of a technical architecture to implement a business processes is the design of the Logical Architecture.  Logical Architectures are critical for two reasons: (i) because requirements are one hundred times cheaper to correct during early design phases as opposed to implementation, and (ii) because logical systems are where the social elements of software systems are implemented.  Requirements gathering will naturally throw up a varying range of features, technical requirements, operational dependencies and physical constraints (non-functional requirements) that Solution Architects inevitably miss.  Their focus and value is on sourcing and vendor selection rather than the capture of the subtleties and complexities of human social interactions and the translation of them into architect-able business constructs (that is the role of the Business Analyst).

The second failing is the development of Trade-Space.  This is the ability to make trade-offs between logical designs.  This is the critical stage before freezing the design for the technical architecture.  This is also vital where soft, social systems such as knowledge, decision making and collaboration are a core requirement.  However, trade-space cannot be affected unless there is some form of quantitative analysis.  The usual outcome is to make trade-offs between technical architectures.   Like magpies, executives and designers, by this stage have already chosen their favourite shiny things.  Energy and reputation has already been invested in various solutions, internal politicking has taken place and the final solution almost eschews all assurance and is pushed through the final stages of governance.

With proper development and assessment of trade-space, companies have the ability to instantiate the complex concepts of front and middle office processes.  Until  now, business analysts have hardly been able to articulate the complicated interactions between senior knowledge workers.   These, however, are far more profitable to outsource other than more mechanical clerical work which is already the subject of existing software solutions.  The higher pay bands and longer setup times for senior information work makes executive decision making the next frontier in outsourcing.

Service offerings

Logical architectures are not usually developed because there is no easy, standardised means of assessing them.  Despite the obvious cost effectiveness logical architectures most Business Analysts do not have the skills to design logical architectures and most Technical Architects move straight to solutions. Logical Architectures which are quantitatively measurable and designed within a standardised methodology have the potential to give large technical service and BPO organisations greater profits and faster times-to-market.

The future is already upon us.  BPO and enterprise services are already highly commoditised.  The margins in outsourcing are already decreasing, especially as cloud-based software becomes more capable.  If high cost labour companies (particularly those in based in Western democracies) are to move to more value-added middle and front office process outsourcing then they will need to use logical architecture methodologies to design more sophisticated offerings.

In the next blog we will show one method of quantitatively assessing logical architectures in order to assess trade-space and make good financial decisions around the choices of technical designs.

Enterprise Architecture:why EA programs fail to deliver Reply

Enterprise architecture has long promised the alignment of the technical ICT of the organisation with its business strategy.  For the same length of time it has steadfastly failed to deliver this.  In order for enterprise architecture to (a) deliver alignment, and (b) execute strategy it must incorporate commercial concepts within the metamodel so that it may directly use both financial analysis as well as legal parameters.

Enterprise architecture has never been solely about infrastructure.  Enterprise capacity can easily be catered for in data centre management.  Enterprise architecture has been largely focused on enterprise applications integration.  Integrating data models and their schema across the distributed enterprise to create harmonious workflows for the fewest people promises to realise the goal of reducing labour whilst purchasing the cheapest software.  Enterprise architecture should be about driving the development of ICT architectures and business process directly from the value chain.

Enterprise architecture still provides businesses and departments with the greatest hope for the harmonious analysis and development of the enterprise.  It fails largely, however, for the following reasons:

  1. Complexity of Metamodel.  Financial language is not generally incorporated in the language of metamodels.  It is possible but not generally done.  When I was at EDS Value Management was an architectural discipline within the Agile RightStep® architectural framework.  Whilst at Serco a number of us tried to incorporate value against the various objects in architectural models withing the MEGA® modelling suite.  However, in order to take advantage of financials modelling tools would need to incorporate stochastic simulations and not just discrete event simulation into their analytical capabilities.  This explains the disparity, often large, between architectural models and financial models.
  2. Systems Engineering.  EA still remains largely focused on enterprise systems engineering.  It needs to shift its focus to enterprise engineering systems.  Where the former focuses on the minutiae of systems interaction the latter is concerned with the integration of one engineering system to another.  If the enterprise sees the financial function as an engineering system then enterprise architects should be able to use their ontological skills in metamodelling to create seamless pull-through of analysis from Finance to Design.  Some of these concepts will be explored in a later blog.
  3. Complexity of Programs.  EA still remains an ICT skill used to support large programs.  In order to capture enterprise relevance it needs to elevate itself from the technically complicated to the organisationally complex.  Given that information systems largely exist to reduce organisational entropy, one of EA’s greatest benefits will be to realise the harmonisation of working practices and not merely implementing monolithic technology.
  4. Lack of Financial Relevance.  EA needs to support value management and not just technology management.  This is as much a problem of program selection as it is the extension of the metamodel.  Automating the Balanced Scorecard  still remains one of the best initial EA programs there is.  It is relevant to both the C-suite as well as providing a direct and tangible impact on the measurement of strategy execution and financial management.

The answer, therefore, is to focus on capabilities and not on architectures.    The former delivers measurable commercial value but the latter will consume the enterprise in a needless pursuit of perfection.  In our next blog we will examine how to architect capability directly from the value chain.

How will enterprise Architecture Reduce Legal Costs? Reply

In mid 2009 I received an e-mail from Mark Hurd, then CEO of Hewlett Packard.  This wasn’t unusual because I was at EDS UK and we all got an e-mail from our new CEO.  He wanted to explain that over and above the 26,000 people he was already getting rid of in the new enterprise there would be further reductions.

Why?

He went on to write that earnings were down 20% so his investors wanted to know when he was getting rid of another 20% of his workforce.  He went on to add that he was resisting their advice as it would hurt us on the rebound.

Clever Mark.

The point of the story is how one determines, precisely and effectively, what are the right parts of your cost structures are the ones to get rid of?  Typical commercial reasoning suggests that the best cost structures to cut are: headcounts, marketing, training, procurement and travel.  These are the easiest but you don’t have to be Lou Gerstner to realise that you shouldn’t cut marketing or travel in a downturn.  Pick up any edition of HBR and you’ll know that you need to focus on core business and cut the rest.

So how do we find core business and what on earth does it have to do with my legal costs?

Have you ever done a push-up?  What muscles do you think are used? Chest? Yep. Triceps? Oh yeah.  What about anterior deltoid? What about the supraspinatus or the infraspinatus or the teres minor? What about the teres major and the suprascapularis? These are all synergistic muscles in the push up that help hold your shoulder girdle stable and stop you toppling over to one side.  Likewise with business.  There are an enormous number of synergistic activities which assist core processes.

Don’t worry we’re getting to the bit about legal costs.

Your core business will be the fundamental raison d’être of your company.  For instance.  You might think that you own a network outsourcing company but when you ask yourself why your company really exists and what it seeks to really achieve, you might find the answer being that it transforms the customer relations of client companies? Now you need to determine what are all the essential processes which support transformation (which we’ll look at another time)After that one must discover the dependent, people, information, systems and infrastructure for these processes.

That’s the easy bit.

Now you need to architect it into some form of commercial reality and make it happen.  Once this beautiful strategy is executed in a new and improved operating model you will be left with a pile of paper which enshrines the agreements you have made with partners to make this reality.  Contracts – and they don’t come cheap.

Did you notice a theme?  I talked thereabove about the seamless architectural process which blends to bring synergy to the design and form of your new business.  The realistic amongst us will know there is always a great crash as the momentum behind any deal brings it into contact with the immovable object of the law.  The beautiful deal we created is then mangled through lawyers until what we wanted is barely recognisable.

What if this horrid legal process was an integrated part of the architectural process?  What if our business architects, our technicians and deal-makers were all joined in a common, collaborative architectural process which derived legal clauses directly from the technical and commercial detail of the deal?  Wouldn’t the contract then become a dynamic and fluid document which formed part of the management of the program?  Wouldn’t the contract(s) be lean, precise and swift to negotiate and put in play?

Welcome to Citadel, where enterprise architecture meets the law.

The Architectural Enterprise: financially lead capability development Reply

Image

There is one truism in the world of enterprise architecture, namely:  do not focus on developing the architecture first.  In other words, enterprises should focus on developing capability and not architecture.  Focusing on architecture can only ever gild the lilly. To focus on architecture first is to focus on systems first and not value.  To focus on architecture first is to focus on structures first rather than functions.

Enterprise architecture programs have received poor reviews in the past few years and most even struggle to leave the comfortable boundaries of the all-too-familiar systems rationalisation through data model interoperability.

Architecture, however, should not be the focus.  The focus should be value and the means to achieve this should be through organisational capability.

This bog is Part I in how to develop a comprehensive enterprise architecture program within an organisation, namely:  developing a capability portfolio.

STEP 1:  Value.

The best way to define value in an organisation or department is through variance analysis (so long as this is performed well and to at least 3 degrees of depth) in the relevant business unit.  In the Architectural Enterprise (the fictional enterprise built and run on EA guidelines) the specific variance would be referred to an Architectural Council to ensure that the variance was cross-referenced for dependencies and all the ‘noise’ was stripped away, i.e. personnel as opposed to role issues. The architectural team can now focus on supporting the process, service delivery or value activities.

Alliteratively, if the EA program needs to start more stealthily, then the ICT department may begin by cost-modelling the ICT budget.  The financial model needs to include 3-point estimates for all relevant costs.  Importantly, the higher bound is what the organisation does pay, the middle bound is what they should pay, and the lower bound (the 10% CI) is what they could pay.  This forces the team to not only to prep the model with uncertainty (for later simulation) but also to make sure that realistic stretch targets are imposed for projected cost reductions.

Once the model is run through a deep sensitivity analysis the team can then strip out all non-capability cost drivers, such as internal transfers, tax liabilities, interest and depreciation etc.

STEP 2:  Capability.

What is left are the most sensitive capability cost drivers.  The team now needs to make sure they focus on what is valuable and not just what is sensitive.  This is critical to ensure that the team doesn’t focus on low impact back-office ICT enabled capability but rather on high-impact, high-value operational capability.  The key is to ensure that an accurate value chain is used.

The best way to achieve an accurate value chain is to (a) develop a generic value chain based on industry baselines and then, (b) refine it using the firm’s consolidated financial returns.  The team should work with a management accountant to allocate costs amongst the various primary and supporting functions.  This will highlight exactly where the firm (i) derives its primary value, and (ii) along which lines it is differentiated.

Once the team understands these financial value-drivers and competitive subtleties they can now calibrate the capability-cost drivers with the value chain.

STEP 3:  Architecture.

Once the team has a short list of sensitive areas which are both architecturally weak and financially valuable they can then set about increasing the capability within defined parameters.

To do this, the team needs to create a parameterised architecture.  The architectural model has two facets: (a) it has capability components enabling it to encompass the dependencies of the area the team is focusing on, and (b) the capability components have attached values.

Determining values for model is oftentimes difficult.  Not all components of capability have easily defined financial parameters.  What value does the team place on information?  on processes? on services or even on task functions in certain roles?  Although this will be the subject of another blog the intangible aspects of capability must all affect the 100% of financial value.  For instance, a Role filled to 80% (due to shortfalls in the person filling the role) will not necessarily mean that the capability runs at 80%.  For a good set of capability coefficients the team can use the COSYSMO model elements. These coefficients allow the team to see how the overall cost is varied by differences in organisational capability.

Once the architectural model is built the team can adjust the parameters so that they achieve both the cost that they could deliver whilst making sure that they are also increasing overall capability, i.e. process output, software integration, role utilisation etc.

Whereas standard cost reduction programs reduce cost without accounting for the wider capability sensitivities, this methodology is able to model a capability financially yet cognisant of how intangible aspects support its overall enterprise value.

IN SUMM

Through this method the team is not only able to identify the areas requiring attention but they are also able to ensure that that costs are reduced without compromising overall business capability.  Moreover, the team will be able to do this whilst engaging with both the technical and the financial teams.

Most importantly, by focusing on capability and not architecture the organisation can hone in on not just on the hot-spots – because their will be too many to count – but on the valuable hot-spots.