I’m very much of the view that every business is a technology company. Trying to say that they are not is not only fooling themselves but setting their business’ up for a failure. Over the last six to twelve months I’ve been looking at the practical application of business mapping. This is all courtesy of the work of Simon Wardley and his sharing of something he has been doing for some time. In the process of taking these concepts and applying to my every-day job as an Enterprise Architect and recent undertaking of a Masters degree I’ve pulled together an expanded view of how to apply this, not only to my business, but for customers wishing to outsource.

Simon’s view – See insert image “Simon Wardley – Value Map”

Simon Wardley – Value Map

This is Step 4 of Simon Wardley’s basic’s of business mapping  – http://blog.gardeviance.org/2013/03/basics-repeated-again.html 

I’ve added a little something to it as I’ll discuss below.

Ideally you would start with a business map and decompose it, but in my role as an Enterprise Architect I find that I’m forced to take a technology centric view and then shape everything around it. Ultimately the outcome is the same. A holistic view of the business’ make-up (value chain), the technology that supports it and the trajectory of the evolution and value of the technology over time.

The following is how I’ve taken the simple technology road-mapping, paired it with market audits and then used that to create a view on business mapping that puts the humble technology roadmap in context. There are a number of tools I’ve used, they are not definitive, nor are they necessarily the best ones. These are the ones that have worked for me.

Technology Roadmaps

Let’s put it in perspective, what is a technology roadmap? As wikipedia points out – A technology roadmap is a plan that matches short-term and long-term goals with specific technology solutions to help meet those goals. Mapping of any sort shows the hows (and potentially whys) of attaining technology goals. These can be presented in any number of ways. The most popular are in diagrammatic format with little boxes or bubbles that group capabilities together and show the different states. There is also examples where capability can be linked in a hybrid view showing capability development over time with a Gantt chart. Google it if you don’t know what I’m talking about. Here are a couple of examples and a close crop image of one from Enterprise Architects below:

Enterprise Architects – Reference Architecture Example

Context for Technology roadmaps

Why do we create technology roadmaps? Some people do it because they just do it and have little understanding of the use of roadmaps (been there and done that myself because it was a contractual deliverable), others to illustrate what they are thinking. The reality is that it is for helping customers (internal business users are customers too) understand the technology, current and future, that is at work in their business. It shows managers and executives a clear view of their current investment of technology and the linkage between the different investments. It sets the scene for asking “Why?” and helps businesses with investment planning. But the technology investment view is only a very small part of the puzzle.

Market Audits with trending

Looking at just  roadmaps of technology, and what capability you need as a business, is only a part view. To make sure that you are not only addressing the business’ immediate and projected needs but also not setting yourself up for failure, you need to have a larger view of the product/capability and what is playing out in the wider market or landscape. This is know as a market audit.

What is a market audit?

A market audit is the term for process of reviewing the landscape and determining the product fit within the market itself and various hierarchies of business strategy. Kotler (2009) had a number of questions that should be answered in the process of the market audit including:

• Current market situation – What is happening now in terms of size, growth, and segments within the market?
• Product situation – What is the organisational view of sales, product, prices, margin and profits for the products(s) being reviewed?
• Competitive situation – Who, or what are your major competitors?
• Distribution situation – Who are your major collaborators for growth, size, goals, etc?

These questions only glance the surface of all the questions you need answered, however, they are a very good start. This audit will allow you to better understand the various forces at play and how they will affect your business. These are all extremely important when moving on to business mapping. Previously I’ve approached the landscape analysis (as I used to call it) in a piecemeal way. During my recent studies I’ve come across a number of different tools that can be used together to create a more complete view.

There are a number of tools and techniques that you can use to help review the environment; the external forces, internal forces and interaction of them on each other. Below I’ve exampled a couple I’ve used.

External forces

I found the PESTLED analysis technique very useful in looking to understand the opportunities and threats for a given capability, product or service.

• Political – Legislative constraints that may affect your audited capability.
• Economic – Customer buying power
  • Macro – what is happening in the larger political-economic sphere. As Simon has pointed out in the past, Hayek and Keynes are good ways of viewing the manipulation of the economic factors at play.
  • Micro – What you see individual business doing with regards to their spending habits. In this case, what my target potential customer’s trends are and how they compare to the generalised trends of their peers.
• Social/Cultural – The generic values attributes and benefits expected from the capability
• Technological – Changing markets through technological advancement. What is emerging and what is trending for the capability. You can take the time to audit the environment yourself, or use a number of sources like IDC, Gartner and Forrester for the mainstream, or smaller boutique and specialist firms that target your chosen capability, to point you in the direction. Whilst I don’t think that they are always on the money, they will certainly give you a good view of the wider industry and trends.
• Environmental – What are the environmental expectations or considerations you need to make.
• Demographical – Population breakup and markets within it
  • People = consumer focus
  • Organisations = B2B

Internal forces

There are a lot of internal moving pieces that make up a business and you ned to understand how they are used to support the capability, product or services you are auditing. Understanding how each of these affect the component in question will help you understand the inertia a business faces when trying to move on past one phase of the capability evolution into another. These are the business’ strengths and weaknesses.

• Company – all parts inside and those that feeds the business
• Customers – the people that buy
• Suppliers – Raw material/inputs to allow the creation of products
• Intermediaries – Or marketing channels that help crate and deliver value.
• Competitors – Those that can limit your success.
• Publics – any group that has potential interest in an organisation.

Porter’s 5 forces analysis

Whilst this is generally used by businesses for product development there is a lot of use in this when mapping out the landscape and understanding the various market forces that could be at play, Figure 1, below.

Figure 1 – Porter’s 5 forces

• Rivalry amongst existing competitors
  • Driven by: numerous competitors; slow growth; high exit barriers; committed rivals.
• Threat of new entrants
  • Low entry cost = high threat. Prices must be kept low or high investment to deter competitors
  • High entry cost = low threat. If there is a threat, profitability will be kept low.
  • Barriers to entry are:
    • Supply-side economies of scale
    • Demand-side benefit of scale
    • Customer switching cost
    • Capital requirements
    • Incumbency advantages independent of size
    • Unequal access to distribution channels
    • Restrictive government policy
    • Expected retaliation – how potential entrants believe that they will be received, and how this will shape their strategy
• Threat of substitutes
  • These can be direct or indirect substitutes that perform the same or similar function. Causes profitability issues.
• Power of buyers
  • The more powerful the buyer, the greater their ability to force down price, keeping value for themselves.
• Power of suppliers
  • The more powerful the supplier the more value they keep for themselves (through higher prices)

Affect on roadmap mapping

What all of this does is forces you to cast aside any preconceived ideas on what it is you think the best implementation of capability, product or service should be and look at what it NEEDS to be given the various influences at play.

In the provider (technology or services) space you can also use this technique to identify trends in approaches. These may buck the trends that you think are happening and allow you to ask more questions.

Business Mapping

Now on to the important part, business mapping. As I originally said, the business map should ideally happen at the beginning, however, in the process of looking at all these various capabilities that the business uses you will have started to get a very good view of the individual landscapes involved in delivering the products or service your business markets. The trick is now pulling this all together. this is the business map. I’ll use a completely fictitious map for this as I don’t wish to offend anyone (past or present employers included). For an overview of business mapping please see Simon Wardley’s blog here.

As Simon points out it really starts with a value chain view of the organisation (actually it starts out with the business identifying the need that they are addressing, but I’m skipping that, very important part).

Figure 2 – S. Wardley – Value Chain

This is then mapped to the evolution cycle. There are a number of different ways that you can do this:

• Simon Wardley’s model
• Gartner Hype Cycle
• other

I’ve chosen Simon Wardley’s model of genesis through to commodity/utility as it works really well for a number of other applications. Figure 3:

Figure 3 – Start view of value map

Using the market audit you will have identified that some of these capabilities have a certain trajectory from bespoke or product through to commodity and utility (Figure 4). This not only shows the relationship of each area of business and technical capability, but it also clearly identifies the perceived value the business places on each piece. The trajectories can show where the industry trends see those capabilities and provides the business a view on where their future should be, unless there is a really good reason for not (Figure 6) going that way.

Figure 4 – Projected view

This starts to highlight a number of trends, especially popular are those capabilities that are now being delivered as a Service (aaS), see Figure 5.

Figure 5 – aaS option view

Figure 6 – aaS where value it soo great

What I started to see is that there starts to exist an imaginary line across the graph where management of the capabilities are clearly considered too valuable to push outside the boundaries of the organisation, despite its place in the lifecycle, Figure 7. My own interpretation of this is where a business is with its maturity in approach to IT, though occasionally affected by regulation.

Immature –  insourcing components that are obviously products and services that can be obtained externally, arguably cheaper and potentially more robust, through FUD (fear, uncertainty and doubt).

Legislative constraints – Forced to insource.

Or mature in business and outsourcing – taking the low value new-capabilities and bespoke builds, pushing the risk and pain of development external to their core business, bringing it back in-house once it has proven its worth and demonstrated value.

This can also explain the ongoing war between private and public cloud people. It all comes down to the specific use case and reasons behind the decisions to insource or outsource.

Figure 7 – Managed services view

These maps now arm the technologist, and business professional, with information that can be used to understand the overall business’ direction and what factors influence the various capabilities that underpin the central need of the value chain. Providing context for recommendations and decisions.

Update: Based on some questions and feedback I’ve added an example of a reference architecture and some links as well as a link to Simon Wardley’s blog for an overview on business mapping.

It has been some time since I felt inspired enough to put fingers to keyboard and create a new post. That changed when a friend of mine, recently released his Architects Manifesto in which he summarises his 10 points for delivering good Architecture.

Architect Manifesto:

Whilst I pretty much agree with this call to action as it stands, I thought I’d delve into the points myself and add my own perspective, as there is a little repetition in there. Each one of these I could probably write enough material to fill a book, a wildly disjointed book that is. Instead I’ve put together my high level view on each point.

1 Provide true value-add to clients. Just adding value is no longer enough

We live in a day and age where marketing hype is designed to make us believe that because a product or service exists, we need it.

Value, as we all know, is a relative statement. In order to provide something of actual value you need to know your audience. As cliched as it sounds, what keeps them up at night, goes a long way to understanding what they care about. If you can address those cares you can show true value.

2 Commit yourself to being an architect and technologist, rather than acting like a ‘techie’

An Architect is someone that “works with stakeholders, both leadership and subject matter experts, to build a holistic view of the organization’s strategy, processes, information, and information technology assets.”  and a Technologist is someone that uses technology to solve practical problems. Being an Architect and a Technologist is taking that holistic view and applying technology, and services, to solve business challenges.

Contrast these to a “techie” who is looking at the shiny and the cool features and functions that exist, doing stuff with them because you can, not because you need to.

3 Solve client business challenges instead of simply fixing technical problems

As covered in the last point, in our role as Architects our job is to look at how to fix business challenges (or problems) with technology. But to fix the problem we need to know what the problem is. this too goes back to the first point, know your audience.

This is vastly different than looking at technical issues and working out how to make it better. It doesn’t require you to know much about your audience at all. This is also why this is the easy way out for most.

Most of the time what comes to us is a technical problem, or an abstracted view of what the real issue is. The trick is to ferret out the underlying business challenge that needs to be addressed.

4 Architect compelling and cost effective solutions that close business

Before you cry out “what has closing business got to do with it?” think about what happens when there are no more projects. Very soon there will be a whole lot of people without a job, including you!

If you are pulling together solutions that solve actual business challenges with technology or services that are of actual value, chances are you are 90% of the way there. When you look at delivering the solution in the most cost effective manner you are home and hosed.

Cost effective can me a lot of things, but put simply, how can you resolve the challenge in front of you in the cheapest way. Can the solution be only 85% of what people want? Can you deliver it a different way? Is there a smarter way to cut the financials to make it more viable? You won’t know until you look.

5 Ensure client satisfaction instead of focusing on increasing customer satisfaction scores

When you take in the full picture of what it is you are trying to address, looking at all the stakeholders for the specific business concern, the more you work an understanding your audience, or customer, the more focused and tailored your solutions will be. This in turn will ensure satisfaction.

6 Don’t just build solutions with cool technologies; focus on building profitable solutions

This goes back to point number 2. Often as ex-techies we Architects love us some cool tech. If you have been keeping the previous rules 1 through 5 you should be in good standing. For me where this comes into play is if, when building your solution, you don’t reach back into the standard kit-bag you possess as a business to deliver what is needed.

If you reach for that latest and greatest bit of tech BEFORE you have a look at what you already have access to that is good enough you are potentially going to have something that is more expensive to build and run. That said, sometimes the new thing is cheaper and does a better job.

I look at this with my outsourcing Enterprise Architect hat on and how I know that for the most part customers are looking for cost effective solutions. When you bring in the new and unknown, you introduce risk. Risk equates to money and whilst you can  estimate what this might be, there will be a lot you don’t know. At best you bake in a risk contingency to your cost, worst case you end up getting caught out doing a large amount or remediation work at your own expense. This kills profitability and the financial viability of the solution as a whole.

7 Maintain leverage and objectivity when working with vendors and partners.

The one thing to remember when working with vendors and partners is that they want to maximise their

components of the solution you are pulling together. If you are looking after rules 1 through 6, when you get here you won’t have much in the way of issue as you will have a clear view on what the business concern you are addressing is, what specific bits of technology you need to address it and the value of your solution to the business.

Remember, you are only bringing in a partner or a vendor because there is something specific you need.

8 Create intellectual property and sustainable competitive differentiation. Do it!

This is a hard one. Many times we as Architects reach into the kit and and find that there isn’t the tool or appropriate building block available, so we create something new to fill the gap.

My thoughts on this is that if you work on the other 9 points, and do it well, this will fall out the bottom quite nicely, however, the trick here is to understand what it is you have done. Rarely will you be immediately aware of this yourself and this is where I find having a team to support you comes into play.

Whilst your head is down developing solutions that meet points 1 – 7 and 9 – 10, you won’t necessarily know what gold you have produced. In the peer (critical) review of your work, this will come to light. It will be honed and the nugget you have at the end needs to be understood and passed on. So many times I see Architects re-inventing the wheel where there was work that could have, should have, been  built on top of.

9 Know the competition; understand their value proposition, and solution to win.

You spend months pulling together that perfect solution and writing up the value proposition, only to find you’ve been pipped at the post by someone else.

Now there is nothing wrong with having a component of a solution that is a “me too”  offering, but you need to understand why yours a) has value and b) has unique value to that of the competition.

If you don’t take time out to understand what else is out there, what is in their bag of tricks (solution building blocks) and how they position their unique value, you will be doomed to failure, because I can guarantee you that they are making sure that they know yours.

10 Deliver real innovation to clients. Simply being innovative doesn’t cut it anymore.

To me this is calling something “innovation” when it is not. Building something that is looking for a problem is not really innovation, neither is an incremental improvement on what went before.
Innovation is the development of new values through solutions that meet new needs, inarticulate needs, or old customer and market needs in value adding new ways. Nuff said!

Summary

It’s all been a bit quiet here, that’s because I’ve been buried in a piece of work that threatened to eat me. So far I’ve made it out the other side and I’m still kicking. What doesn’t kill you makes you stronger right? Apart from not killing me It’s forced me to reevaluate my options.

As with the Dylan classic “The times they are a changin'” it’s time to stop look about and instead of demanding the old guard get out of the way, go on and forge my own path ahead.

Whilst the road I’ve travelled so far has been at times a rough one, it was certainly an interesting one that allowed me to meet and work alongside some amazing people that I’d not otherwise have had the ability to interact with.

I’m looking forward to the new gig, it’s a move away from being strongly technology focused, that is a little scary in of itself, but should start opening up other new and exciting things to learn; Some things I’ve already been playing with behind the scenes already (they will start popping up on this blog no doubt).

The line it is drawn
The curse it is cast
The slow one now
Will later be fast
As the present now
Will later be past
The order is rapidly fadin’
And the first one now will later be last
For the times they are a-changin’

Image Source: Rogers' Security Blog

Have you ever noticed that if you stick 3 security professionals in a room you’ll get 3 different opinions?

That’s the first thing that popped into my head when I was asked to explain what security is to some colleagues.

What is Security

• Security is to protect against malice, error and mischief.
• It is ultimately a trade-off. To get some “security” you need to give up either money, time or convenience (personal freedoms); in order to feel or become secure.
• It is a function of “duty of care” that a business must provide.

OK the longer version – What is it?

Security is ultimately identifying and managing risks, most of which are based on fear (and to a lesser extent Uncertainty and Doubt – FUD) and is something every one of you think about and deal with everyday. From where you sit on a train to where you park your car to what street you walk down at night, you think about what could happen.

Enterprise Security attempts to put a formal framework around identifying these fears, remove the emotional baggage associated with FUD and arm those that have to make the decisions.

“But that’s not my experience.”

You might say “but that’s not my experience”. Technology Security, specifically in the Enterprise, has generally been approached in a piece-meal, or point solution, fashion for a very long time. The market has played with our emotional baggage and driven the FUD factor causing businesses to buy that one product that will bandaid/cover that potential flaw in that critical system whilst failing to address the root cause.

We know we need to have building, infrastructure, information and policy security as well as risk assessment with a bit of compliance thrown in the mix, but for a very long time they have been delivered by completely different areas from within the business; Facilities, IT, HR and Finance, cobbled together in a fashion where Security is almost an afterthought and where it will been seen by everyone as business prevention.

Today, as organisations have matured, Like IT services in general, Security is becoming considered an integral part of the business’ development.

A Relative term.

Remember when I asked “Have you ever noticed that if you stick 3 security professionals in a room you’ll get 3 different opinions?”

You need to remember that, for the most part, security is a relative term. Each person has a certain view on each topic e.g. I don’t like catching the train at night due to bad experiences, whereas my wife prefers to catch the train (over getting in a cab for instance – though the Australian Bureau of Statistics isn’t all that helpful when wanting to do that sort comparison).

Work related example:

– How do you feel about sharing your passwords?

– What about password sharing in manufacturing, warehousing or retail environment?

– how would the managers of these staff view sharing of account details?

– Now what about management when something like PCI comes into play?

Each component in a Business environment, or eco system, has different values to different people within an organisation, let alone between organisations.

Security within an Enterprise tries to take these disparate view points and consolidate into a formalised view addressing the various needs of the business, as well as key individuals, ideally removing as much FUD as humanly possible.

Where to take security today?

The idea is to take Security and turn it from a HAZMAT suit approach to an immune response. By that I mean to stop trying to wrap the business in a preventative/protective shield for the “just in case” or “worse case” and move to a more dynamic stance where you are able to cope with changes by applying business logic to any given situation.

But How?

There are a number of formal Security Architecture, Risk Management and Governance frameworks and methodologies (and to a lesser extend ontologies) out there to help like ISM, PSPF, SABSA, Zachman, COBIT, ISO/IEC 31000, ISO/IEC 27002, and TOGAF (OK the first two are Australian Government standards, but hey they fit the bill).

These play a role, of varying degrees, in overseeing the design and build of Business Systems which are;

• Free from fear;
• in safe hands;
• not likely to fail;
• safe from attack.

These all provide the formal framework for identifying the requirements and risks (fears) and work to remove the emotional baggage and apply some sense to how they are addressed, arming those that have to make the decisions.

There are a lot of great resources out there, both generic and specific to issues, they are but a Google search away.