7 November 2014

The Augmented Human: Implantables – A “Hypothetical?” Product Roadmap



A short while ago I tweeted on the issue of brand loyalty using an oft used sci-fi technology as a talking point. It went like this:

“If you think brand loyalty is essential for take up of wearable technology imagine how important it will be for implantables!”

We’ve all seen films where people are augmented with a variety of implants that allow them to interact with the world and each other without resorting to clunky old-fashioned devices such as smart phones and tablets. At the same time however, we challenge the idea that people would be willing to have such implants – the leap from purchased product to surgical intervention is simply too great to envisage.

This got me thinking about what such a technology could do, and what it would take to introduce it to the market given the invasive and potentially permanent nature of the devices involved… and this is how my thinking went:

From Little Acorns
The best way to introduce radical transformation into the lives of change averse human beings is in small, imperceptible but beneficial steps. However, even small changes are difficult to introduce and so we have to find an audience receptive to that change. This audience is typically the young and/or the adventurous. So, as for many emerging technologies, our target audience might be teenagers.

We then need a single, incremental change that can be made to their existing lives that will provide benefit and at the same time make the greater changes we intend to make more palatable.

Imagine a large corporation has just purchased a trendy brand of headphones and sees this as the channel for introducing implantables onto the market. Imagine that this corporation has access to miniaturised technology that allows a microscopic passive device to be produced that vibrates when exposed to an external signal (e.g. from a smartphone), and that this device is suitable for insertion under the skin near the eardrum (maybe at a reputable ear-piercing establishment). For purposes of brevity let’s call these devices “Beatbuds”.

Now, imagine I’m a teenager and I want to listen to my music in an unobtrusive way, and perhaps even surreptitiously at home or in college. I might consider adopting these Beatbuds as my headphone of choice – after all, they’re not really implantables are they? They just go under the skin.

One Step Leads to Another
So now we have a group of customers able to listen to their music without wires and without any external appendages. They can even use their Beatbuds for phone conversations (but of course they then annoyingly have to hold the phone up to speak into it. Imaging how much easier it would be if that same ear-piercing establishment could insert a similar passive device under the skin of the neck close to the voice box. Of course, if I’ve already had the first implant I’m not going to hesitate on the second as it completes my ensemble.

Now I can use my audio devices completely hands free – voice can be used to control the device, have proper conversations with my friends and even create short textual updates such as Tweets. With practice I can even use voice to create longer pieces of text.


Hands Free... To Do What?
But, voice input for commands is so difficult sometimes, especially in a noisy environment or when I want to keep my communication to myself. Wouldn’t a few of those passive microphones also act as touch sensors? After all, that’s why we have finger prints – so that when we hold something or run our fingers over them the resulting (sound) vibrations create a sense of touch and movement.

Can I have one in each finger, please, and could you then create a touch based interface into my smartphone so that I can use my hands to create messages and control what happens. (And, by the way, that smartphone of mine has no microphone or speakers now so there should be room for more battery and processing power, and if my fingers are touch sensitive any surface will do and the screen no longer needs to be touch sensitive so you could project it onto that surface.

Better still, maybe those finger implants could have basic accelerometer capability so gestures in the air can also be used, and if we reuse the Beatbud technology they could also vibrate to give us a form of force feedback when we touch a virtual surface as well as a real surface. 

See What I Mean?
That was going so well. I’m bought into the implantable model and I’m creating a full implantable eco-system that I am not only comfortable with but am rapidly becoming dependent upon.

And then you made me get that damn phone thing out of my pocket to see what I’m doing. If you could integrate it with a head-up display that would complete the picture wouldn’t it? Hang on a minute? If you think I’m going to wear those weird looking glasses when I spent good money on laser eye surgery to avoid wearing spectacles you’ve got another think coming. Keep up with the times – we’re all doing implantables now and waiting impatiently for the optic nerve implant that will complete the experience.

Imagine how great it would be if I could not only hear, speak and touch without devices. Imagine if I could see a virtual world overlaid on the real world creating a much richer and more natural experience. Imagine if I could see what you were seeing with your implants. If when we were talking you could sit in front of a mirror and I could talk directly to your reflection as if you were sitting opposite me. Wouldn’t it be great at work if I could have a truly realistic face to face meeting with you and your colleagues without travelling to your office and without resorting to any video conferencing capability? 

And with breakthroughs now emerging in non-invasive sensors that allow thoughts to be converted into words and direct brain to brain communication having now been achieved via internet connectivity with a matrix of implants in the scalp, why use voice at all?

In the Bad Old Days
“Come to think of it, Dad, I’m not really sure how people managed without all this stuff?”

“Well, Son, I still remember the day when we carried iPhones around and used those old fashioned Beatbuds to just listen to music!”

“What’s an iPhone, dad?”

“You know that little Hubplant you have next to your belly button? Well as little as ten years ago those used to be as big as your hand and you had to carry them around with you if you wanted to do just about anything!”

“Really? Why?!”

Regards
The Enterprising Architect

22 August 2012

EA Quick Start Guide (Part 4): "Application" - Reclaiming the Noun

In part 4 of my series introducing Enterprise Architecture, I will focus on the second of the three layers described in Part 2; the Application Layer. This is the layer in which we apply the components, systems and sources from our infrastructure layer to provide solutions to the needs we have articulated in our business layer. To properly understand this layer those of an IT bent must throw off their belief that an application is a piece of software. For those you are saying “yes it is” as they read this, perhaps a dictionary definition will help:

Application: noun
  1. A formal request to an authority: an application for leave
    [mass noun]: licences are available on application
    [as modifier]: an application form
  2. [mass noun] the action of putting something into operation: the application of general rules to particular cases
    [count noun]: massage has far-reaching medical applications
    practical use or relevance: this principle has no application to the present case
  3. [mass noun] the action of applying something to a surface: paints suitable for application on fabric
    [count noun]: a fresh application of make-upa medicinal substance applied to the skin: an application to relieve muscle pain
  4. [mass noun] sustained effort; hard work: the job takes a great deal of patience and application
  5. (also application program) Computing - a program or piece of software designed to fulfil a particular purpose: a database application
The application layer covers all solutions to a problem, be they IT related or physical in nature. A nominal ledger implemented on paper is as much an application as is a spread-sheet created to achieve the same outcome.

A Quick Reminder
As discussed in Part 2, the application layer of the Enterprise Architecture Describes the high level solutions that need to be provided to support the future intent described in the Business Layer (see the following diagram showing the application layer in the context of the full EA Grid):


As was the case for the business layer, within the application layer there are three key models covering behaviour, structure and knowledge, defined as follows:
  • Capabilities (Application Behaviour)
    Shows the internal application services needed by the business (including IT) to allow it to undertake the processes described in the Services layer.
  • Solutions (Application Structure)
    Shows how the application services interact with one another to fulfil the needs of the Organisation model and thus provide the desired customer experience.
  • Data (Application Information)
    Shows the detailed data elements and relationships required to support the Information model. This data model is derived from the Information model, but at the same time, needs to be supportive of the application services described in the Capabilities model (and vice versa).
I have already recommended that a good architect starts in the corners of the EA Grid and works inwards, and following this principle I will now describe the individual models within the application layer starting from the edges. However, it should be noted that a degree of overlap in the development of these models will be beneficial to ensure that no one model is created without the benefit of at least an overview of how the other two models are evolving.

The Capabilities Model
Starting with the capabilities model provides a framework onto which you can hang your solutions and data. As for the services model in the business layer which articulate the future intent of the business, the capabilities model articulates the application services that will need to be provided (regardless of implementation approach) to fulfil this business intent. The approach taken to producing this model is very similar to that adopted in developing the business service model, but with a slightly different focus. Where in the business layer we focussed on the services provided by the business to the customer, in the application layer we focus on the generic services (or capabilities) that will need to be provided within the business to fulfil the business services. Also, where in the business service model our primary audience was the strategy and analysis community, in the application capability model our primary audience is the design community. As an example, in the business layer we might consider a service that allows us to accept and manage customer enquiries; in the application layer we might consider a generic contact handling capability.

Step 1: Domains
As for the business service model, start with a large blank page (electronic or physical) and first define your capability model in terms of service domains. These domains are high level grouping concepts that separate the application services to be provided within your business into areas of interest. Think of them simply as boxes into which you will place your services so that you and the business can find them easily in the future. A typical domain model for even the largest of organisations should need no more than five to ten domains. In the business service model we had to draw on vision statements and high level strategy to define our domains, but now that we have a fledgling business architecture (as defined in Part 3 of this series) we have a more detailed source of information on which to draw.

Needless to say, this makes the job of defining domains in the application layer more scientific, but also makes it a more time consuming activity. By analysing the services within the business service model you should be able to identify common themes for which you will need to provide capabilities. These capabilities will naturally group into domains and so steps 1 and 2 should be approach in an iterative manner. i.e. have a first stab at your domains (don’t spend more than a couple of hours on this), then discover your services in step 2 and from these services refine your domain model to recognise the families of services that you are discovering).

Step 2: Services
Now start populating this model with the services that you intend to provide to the business to fulfil its obligation to the customer. To do this you need to return to your business service model and look at the processes within it. You will start to see within these processes common activities that will need to be supported by your application capability model and it is these activities that define your application services (e.g. Document Lifecycle Management, Contact Handling, Product Servicing, etc.). Make sure you have captured as a minimum the intent of each service to avoid misinterpretation later, and more importantly don’t forget to map these application services back to the business services that they support! This is an essential step in ensuring that everything in your application layer can be directly related to something in the business layer. After all, if it is not supporting something the business wants to do in the future what is it doing there in the first place? Provided you have the right people involved in this process (those with the authority to formulate the future vision) it should take no more than a week or two to produce the first cut of a fairly inclusive capability model.

Step 3: Functions
Now that you have defined the application services you intend to provide to support the business and linked these back to the business services themselves) you should be able to break these down into the functions that will support these services. Focus first on those that support the business services that are deemed most important to the business’s value proposition, and on those that are felt to be the most “radical” in terms of business transformation.

REMINDER: The term “application” does not just refer to IT applications! A nominal ledger implemented on paper is as much an application as is a spread-sheet created to achieve the same outcome. Not every element of our service model has to be provided by IT.

The definition of application functions is not a purely abstract activity as needless to say, it will help enormously if the functions you propose marry up with functions that are provided in the real world in one form or another. It is for this reason that (despite publishing this part of the guide first) I strongly urge enterprise architects to consider the corners of the model first, and thus populate the infrastructure layer at draft level before considering the application layer in anger.

An example of a functional decomposition might be the definition of a Document Lifecycle Management service into functions such as Template Management, Document Generation, Document Repository, Document Distribution, etc. For an average service, separation into application functions should take no more than a week at most (and more typically a couple of days).

As was the case for the business layer, you will find that there is a strong tendency to fall back on “what we do today” whenever the going gets tough. Don’t forget to regularly ask the question, “is this what you want to do in the future, or is this what you have to do now?”

And that is it. You now have the first cut of a capability model that defines the functionality that you will need to provide in the solutions model to fulfil the future needs of your business.

The Data Model
Defining the application services and functions in themselves is only part of the story. For functions to make sense in a real business context they must be married up with the data on which they operate. In the business layer we created the information model which defined at a high level the data that our business services managed and depended upon. This model was in itself quite flat in nature and we did not focus too closely on the underlying hierarchy of this information. Now we are in the application layer we need to get serious and drill down into the model to define that actual data within these business information concepts. What exactly do we mean by customer, and what data do we need to properly define that customer?

Step 1: Domains
At last, an easy step. In the vast majority of cases it should be possible to simply copy the business information domains that you defined in the business layer. Occasionally it might be necessary to add one or more domains to support information that simply does not manifest itself at the business level, but beware of this as more often than not this is a sign that you have actually missed something in the business layer itself. A good example of this is where IT architects forget to include the IT department as an integral part of the business itself!

Step 2: Entities
Remembering that the audience for this data model is the design community, we can now afford to use more scientific data definition approaches, encompassing the specific items of data required for each data entity, the hierarchies in which they sit, and the relationships that exist between them. This inevitably makes the job harder and more time consuming, but at least you have a business information model from which to derive your application data model. Once again, good prioritisation is key here. Look at your high priority business services and then at the business information entities on which those services depend. These are the entities you should focus on first. Focus at this stage on decomposing a single business information entity into one or more data entities (as a hierarchy) specific to this information entity.

Data modelling is always a time consuming activity, and I’m afraid this is very much the case here. However, if you focus first on the entities themselves, and their relationships and only drill into the individual data items as you move into the implementation phase of a solution, it should be possible to define the data model for a typical business information entity in two to three days.

Step 3: Relationships
Your data entities will not exist in isolation from one another, but we have a head start this time. The business information model already defines the relationships between the information entities from which your data entities are derived. All you need to do now is define the more detailed relationships that these resolve into in the data model. E.g. a relationship between customer and product holding at the business information level might resolve into a relationship between a customer reference and a specific account at the application data level.

Step 4: Discovery and Use
This final step should now be fairly straight forward as you already know which business information entities are accessed by which business services. All you need to do now is define the next level of detail by working out which data entities are accessed by which application services (and functions). For example, previously we knew that the Customer Management business service accessed the Customer information entity. Now we can be more specific and indicate that the Manage Customer Details application function accesses the Customer Contact Details data entity.

The Solutions Model
With the Capabilities and Data model we now understand what we need to do to support our business, but what we do not have are the actual building blocks from which we can create our end-to-end solutions. This is where the solutions model comes in. In the business layer, we defined the customer experience in the form of journeys analogous with a tube map, with clear start and end points, travelling through stations representing the key business services used. We then defined the interactions that the customer has with the business, and the organisation structure that the business plans to put into place to support these journeys and interactions.

In the application layer we can use this organisation model as the context for our solutions. We also have the capabilities and data models in the application layer and so all that is left to do is to tie these together to create our solutions. In traditional architecture terms we are now creating our logical solution designs.

Step 1: Defining the Building Blocks
It is unlikely that we will create solutions to all our needs in one go. Businesses have limited resources to deliver change, and by the time we come to implement many of our solutions anything we put in place in the early days of our architecture may well be out of date. However, every good architecture provides standard building blocks from which solutions can be created, safe in the knowledge that they are following an architecturally compliant path. In order to define these building blocks we need to look back at our capability model and at the application services and functions that we have defined in that model. The architect needs to identify from this model the sets of functions that can realistically be grouped into units of functionality that can then be used to build solutions.

This is where the “art” elements of architecture come in: the art of simplicity and the art of the possible. For example, we might take all the functions from the Document Lifecycle Management service and propose that they be delivered as a single building block (or application component) safe in the knowledge that there are numerous vendors out there who provide out of the box solutions to fulfil this need. Alternatively, we might take our Systems Development service and propose separate building blocks to cover Software development, Change Management, Testing, etc. It is not immediately obvious what the right answer is and opinion will differ widely as to the correct approach to take. There are of course, many ways to skin a cat. There are of course some key things to take into account when making these decisions:
  1. What do you already have within your arsenal of strategic choices?
  2. Are there clear patterns in the outside world that numerous vendors have followed in providing standard offerings?
  3. Are there clear structures in your organisational structure to which you want to align your solutions?
  4. Can you justify grouping the application functions into a single building block based on their relationship to one another, or are you lumping functions together that would make perfect sense when considered in isolation from one another?
As for many architecture activities this will almost certainly be an iterative process accompanied by much head scratching, soul searching and lost sleep. One thing to always keep in mind however is that you should record your thoughts in your model as you go, even if you are not sure it is right. This allows you to revisit your thinking, and more importantly to share it with others and invite their input (be it positive or negative). It is only through this process of sharing that you will create a robust a widely accepted picture. You do have the advantage that you don’t need to go hunting for your requirements in order to define your building block. These have already been provided for you in your business layer in the form of the related business services and information that are fulfilled by the application functions that your building block needs to provide.

Step 2: Aligning to the Physical
Our building blocks tell us what we need to create in order to support our solutions, but they do not tell us from what we are going to build them. Each of these building blocks will of course need a design. At the very least we should take each of these building blocks and link them to the physical world, and to do this we will need our infrastructure layer again. In the component model of our infrastructure layer we will find the physical things from which we can build things. These might be items of IT software or hardware or non-IT items such as stationary, buildings and transport, and we need to define our building blocks in terms of these items. We are now linking our architecture to actual design artefacts and I will not go into detail on this matter here as this is intended to be a quick start to architecture, and not a design guide.

Step 3: Black Box Solutions
And now to our end-to-end solutions, but what exactly is a solution in the context of this architecture? In simple terms a solution is a bringing together of the building blocks defined in step 2 into a single black box to support the handling of a set of related customer journeys by a set of related people. Thus, in a typical internal example we might take all the customer journeys relating to the handling of all our employees’ HR needs, and propose a single solution to support these. Defining what this solution needs to do is fairly straight forward. By understanding the business services from the customer journey that we need to support we can identify the application services and functions from the capability model that need to be provided by the solution. For these services and functions we already have our building blocks from step 2, and so all we now have to do is knit them together to create the solution.

We’re back into design again here so I don’t intend to describe in detail how you might go about this, but suffice to say, you may discover that to provide a reasonable experience to the user of the solution (or in knitting together the building blocks) you discover the need for a small number of additional building blocks that you had not previously thought of. These will need to be added to the model and linked back to the application services in the capability model (which in turn might also need to be updated). This is not a problem, nor is it a failing in your architecture. It is simply a natural part of the iterative architecture process in which the model is subject to continuous refinement.

The Problem Solved
You now have a working application layer (and thus a working end to end architecture) that is delivering solution designs and driving real projects. Through its use to solve real world problems you will be able to continuously refine and extend this architecture to ensure that it stay current.
Obviously I haven’t explained the infrastructure layer yet (which you will have worked on to some extent before the application layer) and that will be covered in the next part of this series. “But why” I hear you ask, “didn’t you cover that first?” Well – two reasons:
  1. People expect architecture to be explained in the order I am covering it here.
  2. How else am I going to tempt you to read part 5?
Regards
The Enterprising Architect

20 January 2010

Agile Architecture – Some Random Musings

In a recent blog post entitled "Enterprise Architecture - The big catch up" James Gardner (a.k.a. Bankervision) posed the question “How did you get your architecture ahead of project’s demands for it?” and invited those with direct experience to contribute. This is of course a subject dear to my heart, and I duly posted my comments. I have since received numerous requests to post my comments as an article directly on my blog, and so here they are (with minimal editing).

Less is More
Rapid development of architecture in order to stay ahead of the project demand curve is a common dilemma, and one which I believe it is essential for all architects to understand (and more importantly to solve). Bankervision moots decentralization as one possible solution, and I would certainly agree that this can accelerate generation of content. Decentralisation on its own, however, does create its own problem in that the more people you have contributing to a common model, the more work is required to rationalise the result and avoid conflicts and contradictions (which in themselves give the appearance of an incomplete architecture and we are back to the original problem).

For me the real answer here is to have less architects, not more, but it is essential to ensure that they are extremely strong characters with a wide range of experience and the courage and confidence to make the necessary decisions quickly in the absence of hard data. They also need to be brave enough to get it wrong as a mistake in architecture is visible to all. (The fear of being seen to be wrong is a character trait that an architect cannot afford to have).

These strong architects need to have a deep understanding of the world of projects and delivery. They need to have experienced it for themselves in order to know what a project wants and what it doesn't want. (A project wants hard answers and ready-made solutions, not vague ideas and lengthy documents). Give them 80% of what they need and they will have time to help you fill in the other 20% (and so the architecture becomes more complete). People don't mind the gaps as long as the bits that are there are of true value to them (and most importantly make their jobs easier).

Now - this doesn't mean you don't involve a greater community in the production of the architecture. A good architect will be talking to a wide variety of people both inside and outside your organisation, and will have their fingers in many pies. They will already know much of what is required and will be able to talk directly to the people who will give them the information they need.

The Crowd versus the Committee
One concrete example of community involvement in architecture is in the Business Architecture I produced in my current role mentoring a newly formed Business Architecture.

Here, in a nutshell is how we did it:

We brought together a variety of people from across the organisation into a hotel for two days with the remit to "Create the Business Architecture" (They of course didn't believe this could be done, but were hoping to plan out how to do it).

I facilitated the two days and on day one put up a straw man domain model for the business based on their core value chain (from their vision/strategy papers) and invited them to tear it down and rebuild it.

Free discussion and copious post-its gave us their version. (Coffee was, of course consumed in large quantity, and the Danish pastries helped enormously).

In the afternoon we had open discussion (arguments?) in which everyone was invited to add to the model the services they as a business wanted to provide to their customers in the future. We asked them to think to the future (an aspirational date of 2015 was used) and be as unconstrained and inventive as they could be (regular reminders were required to ensure this future focus was maintained). The big question was "What would you like to do!" not "What do you do today" or "What do you think can be done". The constant reminder was "Don't worry if it can be done or not - let us worry about that later"

We then looked at what we had as a group to remove duplicates, resolve conflicts and reach a consensus.

By the end of the second day we had the big picture.

We had a single sheet of paper on which the entire business could be clearly seen, in language familiar to the business. There were no gaping holes around the edges as we did not get shoehorned into focussing on the core services in detail to the exclusion of everything else, and we had a happy (if very tired) consensus around the table that we had a picture of how we would all like the business to look in the future.

We also had a framework that would allow individuals to work on the detail of each service without having to worry about the whole, and in the full knowledge that their work would fit neatly into the jigsaw.

Most importantly, we had created the belief in all those involved that architecture was something you could do (and benefit from) extremely quickly and that decisions were there to be made then and there, not to be passed to a committee to discuss.

This BA has now received wide acclaim across the organisation and has been used successfully and in anger on more than one occasion.

Are there gaps? Of course there are, but these no longer seem to matter. People are seeing the value, getting excited about it, and seeing the opportunity to help us to fill in the gaps as a positive thing.

And Finally... Some Tweets
James’ post also prompted some related tweets from myself, which I include here for completeness:
An architect should always have the answer (even if they're not sure its right ;-)
An architecture should be crowd-sourced, not designed by committee. The architect is filter, scribe, diplomat and evangelist.
Everyone has thoughts, ideas and opinions - it is the job of the architect to condense these into deliverable answers.
Regards
The Enterprising Architect

8 December 2009

EA Quick Start Guide (Part 3): Getting Down to Business

In part 3 of my series introducing Enterprise Architecture, I will focus on the first (and foremost) of the three layers described in Part 2; the Business Layer.

A Quick Reminder
As discussed in Part 2, the business layer of the Enterprise Architecture focuses on the future needs of the business by describing what the business intends to provide to fulfil the needs of its external and internal customers (see the following diagram showing the business layer in the context of the full EA Grid):



Within the business layer are three key models covering behaviour, structure and knowledge, defined as follows:
  • Services (Business Behaviour)
    Shows the business services to be provided to the internal and external customers to fulfil the business vision and objectives, and models these services as well defined and self-contained processes.
  • Organisation (Business Structure)
    Shows how the proposed business services fit within the target organisation model, and how these services interact with one another to create the desired customer experience.
  • Information (Business Knowledge)
    Shows the information as understood by the business as a set of entities and includes the relationships between these entities. This information model needs to be supportive of the business services described in the Services model (and vice versa).
I have already recommended that a good architect starts in the corners of the EA Grid, and following this principle, I will now describe the individual models in this order. However, it should be noted that a degree of overlap in the development of these models will be beneficial to ensure that no one model is created without the benefit of at least an overview of how the other two models are evolving.

The Services Model
Although there will inevitably be a high degree of overlap between the three models in the business layer, the most effective place to start is with the services model. It is here that the true future intent of the business can be articulated in a manner that makes sense to the business, and that focuses on the business from a customer-centric point of view. The Services model tells us exactly what it is the Business intends to “do” for its customers.

Step 1: Domains
Starting with a large blank page (electronic or physical) first define your future business in terms of service domains. These service domains are high level grouping concepts that separate the services to be provided by your business into areas of interest. Think of them simply as boxes into which you will place your services so that you and the business can find them easily in the future (e.g. “Insurance”, “Financial Planning”). A typical domain model for even the largest of organisations should need no more than five to ten domains. If your business already has a good idea of where it is heading, and there is some form of vision statement to support this, this initial domain model should take no more than an hour or two to produce.

Step 2: Services
Now start populating this model with the services that you intend to provide to the customer (e.g. “Insure my car”). Approach this in a brainstorming fashion, focusing more on what the business wants to do and less on getting the names and positions on the model right (they can always be moved or renamed later). Keep going until the ideas start drying up and then review what you have, making sure you have captured the intent of each service to avoid misinterpretation later. Take an 80/20 approach to this task; there will be plenty of time to add the services you miss as you develop the model further. Provided you have the right people involved in this process (those with the authority to formulate the future vision) it should take no more than one or two days to produce the first cut of a fairly inclusive service model.

Step 3: Tasks
To flesh out the basic service model you now need to define the individual tasks that will need to take place to provide each of the services (e.g. within “Insure my Car” you might have tasks such as “Produce a Quote”, “Agree Terms”, etc). A question that often arises at this point is “when is it a task rather than a service?” I stick to the rule of thumb that a task is something that can be performed by a single person (or team) and could be performed between cups of coffee. Focus first on those that are deemed most important to the business’s value proposition, and on those that are felt to be the most “radical” in terms of business transformation. For an average service, separation into tasks should take no more than a day at most.

Step 4: Processes
To complete the service model you now need to describe exactly what has to take place to fulfil each task. In my experience, the best tool for this is the old favourite, process modelling. Agree first on the pre-conditions and post-conditions for the task so that the start and end points are well understood, and then describe the steps that need to be undertaken to complete the task. If you have divided your services down into the type of tasks described in step 3 above, each of these processes will probably only consist of a handful of steps (typically between five and ten). Again, for an average task, the initial process should be definable in less than a day.

During each of these four steps you will find that there is a strong tendency to fall back on “what we do today” whenever the going gets tough. As the Enterprise Architect it is important that you regularly ask the question “is this what you want to do in the future, or is this what you have to do now?”

The Information Model
Closely aligned to the Services model is the Information model which describes what the business will need to know to support the service it provides to its customers. This model should approach information from a business centric point of view, and not from a more traditional IT perspective (which is typically adapted for suitability to the applications, technologies and database approaches, and has little meaning to the business). The business should be able to look at the information model and instantly recognise the content in the context of their day-to-day activities, and it is for this reason that this is often the easiest model to populate.

Step 1: Domains
Essentially, the same first step as for the services model, but this time we focus on domains that allow us to group our information according to subject matter (e.g. Customer, Financial, Products, etc.). As before, it should be possible to complete this task satisfactorily within an hour or two.

Step 2: Entities
Now start populating this model with the information entities; the things the business wants or needs to know about. (If you know anything about database techniques and third normal form please resist the temptation to impose your data modelling “experience” on this activity). Approach this in a brainstorming fashion, focusing more on the core things that the business wants to know about, rather than the fine detail (this will come later in Step 4 below). Keep going until the ideas start drying up and then review what you have, making sure you have captured a description for each entity to avoid misinterpretation later. It should take no more than a day to produce the first cut of this model.

Step 3: Relationships
Information does not exist in isolation. Now that you have captured the main areas of knowledge, refine this model by adding the relationships between these entities. Be careful to only link those entities that have a genuine relationship to one another. Do not link entities to one another simply because your business intends to use the information in a related manner. (For example, a Contact will probably be related to a Customer, but just because you intend to use your Contact History information to develop a Customer Insight Model does not then mean that these entities are related to one another).

Step 4: Discovery and Use
As mentioned earlier, the Information model is closely associated with the Services model. Revisit the tasks in your Services model, and show where knowledge is used or captured by linking the process steps to the relevant information entities. Where necessary create new entities (and their relationships) to support knowledge that is described in the processes, but has not yet been captured in the Information model.

In theory, it is possible to skip directly to Step 4, and use the your Services model as the core discovery tool from which to develop your Information model. However, in practice, you will find that your Business already has a well developed understanding of the knowledge it needs to support, and Steps 2 and 3 offer a more pragmatic and efficient approach to developing a draft Information model.

The Organisation Model
With the Services and Information model we have the basic building blocks for our business, but what we do not have is the overall structure to support this, and this is where the Organisation model comes in. This is not just an organisation hierarchy diagram; far from it. This model is more accurately compared to the London Underground map. By laying out the customer experience in the form of journeys with clear start and end points, travelling through stations representing the key business services used, we can show how these services interact with one another to create the desired result.

We can also recognise more clearly how our teams and departments may need to be organised to ensure that the customer journey is as smooth and efficient as possible, and to ensure that departmental handovers happen at sensible points in that journey. I do not recommend that this is approached as a single end-to-end activity. Instead, approach it in a demand driven fashion guided by the Business initiatives and projects whose needs are greatest. By adopting this approach you can assist with the development of projects requirements, ensure that the projects are aligned to the services in the Business Architecture, and leverage the funded resource assigned to the project.

Step 1: Journeys
The first step in joining up the pieces of our Business jigsaw is to identify and map out the journeys our customers are taken on as they use our services. Describes these as “stories” describing what the customer does, and what the Business does for them, and remember to consider the journey taken by the “virtual customer” as their information flows through our processes (not just the part of the journey visible to the customer) as this hidden journey impacts the customer experience. An example of a Customer journey might be that taken by a UK benefit recipient, which starts when they become unemployed and sign on for benefits through to (possibly) getting a new job and the benefit ending. Remember to model the journey you would like the Customer to experience, rather than the warts-and-all one they may have to take at present. Each journey will typically take a day to develop.

Step 2: Interactions
During a typical journey, a customer might interact with the Business on many occasions, and these interactions need to be identified and named. It is important during this step to recognise that although the customer journey might be unique, the interactions within it will probably re-occur in other journeys (for example, Make Complaint, Search for Jobs, etc.). Each interaction can then be modelled as a sequence of one or more business tasks from the Services model. The customer journey can now be added to the “tube map”. The journey itself represents the “track”, and the interactions are the stations along the way. Adding journeys to the tube map allows us to recognise where journeys join and separate and to understand how any departmental structures might cut across the journeys creating a more complicated customer experience.

Step 3: Organisation
As the tube map develops, there will come a point where it is possible to overlay the proposed business structure on this model. Consider the “zones” on the London Underground tube map and imagine these to be your business areas. You can now identify where it makes sense to handle customer interactions in call centres, and where expert teams need to (and can effectively) get involved. Symbols can be added to the “stations” to show where paper is created or destroyed to support your paper removal agenda (if you have one), or to draw attention to any other key events that you need to highlight. This one diagram brings everything together into a single big picture that shows the simplicity or complexity of your Business at the service and organisational level, and facilitates open discussions about the overall impacts of key Business changes.

Voila!
And there you have it. The Business Architecture; done (as Gordon Ramsey might say).

Well, no... Not exactly. What you have done is started the reaction; what you have not done is reached the critical mass necessary to ensure that this activity does not simply fizzle out.

Your Business Architecture will have significant gaps that others can use to challenge its validity. Many areas will need further work to resolve conflicting requirements and ambitions. And of course, the vision for the future is not a static thing. It will change on a daily basis, and your architecture, as an articulation of this vision, must adapt to its twists and turns.

Architecture is a living thing, and Business Architecture is no exception. You will need to continually revisit and refine to respond to the emerging challenges and the immediate imperatives for the Business.

Above all, you must use your Business Architecture, and you must make sure that others use it too. Not as an afterthought to test alignment, but as the core source of information to identify change initiatives, guide projects, and develop requirements.

You’ve just finished the easy part. From now on it gets physical.

Regards
The Enterprising Architect

26 November 2009

EA Quick Start Guide (Part 2): The Big Picture

In this, the second in my series introducing Enterprise Architecture, I describe the layers of what I consider to be a well formed and pragmatic EA model, and what constitutes the "big picture" so often referred to in architecture circles.

The terminology used is my own, and although it bears similarity to concepts conveyed in other architecture frameworks there are differences (there are, after all, only so many words in the English language that are suitable for certain concepts). For those readers already familiar with established architecture frameworks, it is therefore worth approaching this material with an open mind in order to avoid attaching existing preconceptions to the content.

Please keep in mind at all times that in my architecture approach, the model you are creating first and foremost is the future model (often referred to as the “to-be” architecture). Starting with the “as-is” model, in an attempt to record the status-quo is, in my opinion, unproductive in the absence of the “to-be” model. (See my previous article http://theenterprisingarchitect.blogspot.com/2009/08/to-be-or-not-to-be.html for a more detailed explanation of this position).

The EA Grid
Essential to an architecture is a “big picture” that brings together all the concepts into a single easy to understand starting point. An Enterprise Architecture is made up of several self-contained, but inter-dependent architectures, and thus the EA is made up of several “big pictures”, as shown in the following diagram:



The EA Layers
The EA is first divided into three layers (down the left hand side of the diagram) defined as follows:
  • Business Layer
    Focuses on the future needs of the business by describing what the business intends to provide to fulfil the needs of its external and internal customers.
  • Application Layer
    Describes the high level solutions that need to be provided to support the future intent described in the Business Layer.
  • Infrastructure Layer
    Describes the raw infrastructure elements that will need to be provided to support the solutions described in the Application Layer.
It is important to note that although the terms “Application” and “Infrastructure” are commonly used to represent IT concepts, there is no implication that these layers should contain only the IT elements. For example, in a retail environment it is perfectly reasonable to expect to see the components of the distribution network (such as the vehicles, warehouses, etc.) in the Infrastructure Layer.

The EA Models
The layers of the EA are then divided into three model types (across the top of the diagram), defined as follows:
  • Behaviour Model
    Describes how each element of the architecture will behave in isolation and how they will expose this behaviour.
  • Structure Model
    Describes how the elements of the architecture will all fit together to form a coherent whole.
  • Knowledge Model
    Describes what will need to be known, and how this knowledge will be grouped and categorised.
The EA Pictures
Inevitably this grid results in nine “big pictures”. Nine big pictures might sounds like a lot, but considering that this presents the model for an entire enterprise this is a relatively small number of pictures. Also, each performs a specific job, and many people will be interested in only one or two of these pictures. The intent of a big picture is to convey the overall concepts in one single place that can be easily understood and digested before the reader dives into the underlying detail. For this reason, the techniques used to draw these pictures may be different dependent on the environment, but as a starting point the following descriptions should work in most circumstances:
  • Services (Business Behaviour)
    Shows the business services to be provided to the internal and external customers to fulfil the business vision and objectives, and models these services as well defined and self-contained processes.
  • Organisation (Business Structure)
    Shows how the proposed business services fit within the target organisation model, and how these services interact with one another to create the desired customer experience.
  • Information (Business Knowledge)
    Shows the information as understood by the business as a set of entities and includes the relationships between these entities. This information model needs to be supportive of the business services described in the Services model (and vice versa).
  • Capabilities (Application Behaviour)
    Shows the internal application services needed by the business (including IT) to allow it to undertake the processes described in the Services layer.
  • Solutions (Application Structure)
    Shows how the application services interact with one another to fulfil the needs of the Organisation model and thus provide the desired customer experience.
  • Data (Application Information)
    Shows the detailed data elements and relationships required to support the Information model. This data model is derived from the Information model, but at the same time, needs to be supportive of the application services described in the Capabilities model (and vice versa).
  • Components (Infrastructure Behaviour)
    Shows the individual infrastructure components available to the business to perform its daily activities. In a COTS (Custom Off The Shelf) environment which adopts a “buy not build” strategy, there may well be a great deal of similarity between this model and the Capabilities model.
  • Systems (Infrastructure Structure)
    Shows how the infrastructure components interact with one another to fulfil the needs of the Solution model.
  • Sources (Infrastructure Knowledge)
    Shows the sources of the raw data described in the Data model. In an ideal world, these sources will be derived directly from the Data model, but in reality sources may duplicate data, or separate related data as a result of the choices made in the Component model. This model should therefore identify how the duplication and re-combination of data will be handled.
Where to Start
But that is a lot of pictures to consider, and we have to start somewhere. The majority of “traditional” organisations start in the centre by developing the Solution model. This task often falls to IT alone, acting on a variety of unaligned instructions from many interested parties. In my opinion, this is where many of the problems associated with “Big IT” originate.

It is far better to treat the EA Grid as a jigsaw. Start with the corners, then fill in the edges, and finally complete the centre. The corners allow us to better understand how the edges fit, and the edges give us a better understanding of how the middle needs to look. However, as for a jigsaw, if you find a piece that you know fits an area you are not yet working on, don’t just ignore it; put it where you think it belongs.

It is also best to start with the top left corner (the Services model) in keeping with the service oriented approaches that many architects adopt, and then work left to right and top to bottom (still focusing on the corners first and foremost).

Joining the Dots
The full Enterprise Architecture only makes sense if each of the models links to its neighbours to form an overall joined up picture. It is therefore important to ensure that for each type of model (Behaviour, Structure and Knowledge) there is clear traceability from the Business Layer to the Application Layer and from the Application Layer to the Infrastructure Layer to demonstrate how the needs of the business are being fulfilled, and by what.

This concludes the second part of the Quick Start Guide. The overall Enterprise Architecture has been described as a set of interlinked and mutually supportive big pictures, and an initial indication of the purpose and content of each model has been given.

Further articles will follow describing each of the models in more detail, but from this overview a strong architect should be capable of developing models of whatever flavour they choose that fit into, and fulfil the intent of this approach.

And remember... One of the problems with architecture is that when you describe it in words, it always sounds more complex than it actually is in practice. This article simply applies one of the core concepts of enterprise architecture to itself:
Divide and conquer
Regards
The Enterprising Architect

16 November 2009

EA Quick Start Guide (Part 1): How to Set Up an EA Practice

This article is the first in a sequence providing an introduction to Enterprise Architecture suitable for those starting out in the profession, or for those outside the architecture profession interested in what the fuss is all about.

In this first article I would like to address an issue that has particularly bothered me recently; the setting up of an EA practice. Much is made of the activities required to establish such a practice, but in my opinion, the advice given is at the heart of why others are frustrated with the lack of value delivered by Enterprise Architecture in the early stages of its adoption.

What Not to Do
Firstly, let me address what not to do. Common “wisdom” seems to believe that the initial steps should be as follows:
  1. Identify the fundamental principles that the architecture will support.
  2. Establish the governance framework that will ensure compliance with the architecture.
  3. Establish the architecture framework that the EA practice will adopt.
  4. Start to engage with projects.
“What's wrong with that?” you might ask. It sounds reasonable enough at face value, but this approach is unlikely to result in quick acceptance of EA as a valuable activity.

Firstly, of what use are principles to anyone? They are usually a re-articulation of the obvious, and stating them (or more importantly, wasting time word-smithing them) will simply establish right from the outset that your so-called EA practice has every intention of being a talking shop that makes a profession out of navel gazing. What is more, what exactly is anyone else supposed to do with these principles? They can try with all their might to conform to them, but at the end of the day, they are simply words with many possible interpretations.

Principles may be useful in guiding your architects in the development of the architecture, but they are no more use to the recipients of that architect than a set of coding standards (without any code) are to a tester. In reality, principles in isolation are simply ambiguous tools that self proclaimed architects can use to impose their opinions on others.

…And this brings me to the second step. What are you doing establishing a governance framework when (a) you have nothing against which to measure compliance, and (b) you have not yet established the credibility or respect to demand that others do as you say. Establishing a governance framework at this stage also sends out a very strong message that the primary intent of your practice is to block progress, rather than enable it.

The third step is not so contentious, but I would consider it to be too burdensome to undertake during the emergent phase of your practice. In my opinion, frameworks are useful sources of reference information that can be dipped into and cherry-picked as work progresses on your architecture. Use them as you would a dictionary or encyclopaedia. As for the fourth step; engaging with projects at this stage will simply destroy any credibility you may have had, as you will simply be exposing your lack of real deliverables to a sceptical audience. What is more, you will be dragged into the day-to-day point solution world of the project, and become just one more design resource. This will take your architects away from the bigger picture, and prevent your EA from being developed.

What to Do
So what should we do? The hint is in the previous paragraph. The one thing that the organisation needs you to do as an EA practice is develop your Enterprise Architecture. Until this starts to happen, you cannot provide any real guidance or value, and you certainly cannot justify what you are saying if it is not clearly recorded. You will, instead, always appear to be “making it up as you go along”.

For me, the ideal first steps in establishing an EA practice are:
  1. Ensure you have the right people.
  2. Establish basic working practices.
  3. Start building your architecture!
Those are the basic steps. The following sections give some guidance on how best to perform them.

What Makes a Good Architect?
Enterprise Architecture is a skilled, specialised activity, to be performed by a small number of people. One weak link could fundamentally undermine your effectiveness. (This should be obvious, but for some inexplicable reason EA practices more than any other area of business are set up from a random selection of people, rather than those selected for their previous experience, or potential to be architects. Some key attributes required by an architect are:
  1. Ability to communicate verbally, visually and textually.
    Architecture is (roughly) 80% communication. Bad communication will frustrate others and negate the effectiveness of your architecture.
  2. Ability to listen and quickly assimilate new information.
    Architects are always dealing with the future and thus the ability to learn fast and think fast is essential. What you know today will almost certainly be out of date with respect to a true “to-be” architecture.
  3. Ability to influence and enthuse.
    For your architecture to be successful it must be followed, and for this to happen others must be bought into, and enthusiastic about your architecture. This will only happen if your team have the presence and ability to make it happen.
  4. Credibility.
    Some people have it, some do not, and worse still, some have at some point in the past lost it. There is no point in starting with a disadvantage.
  5. Ability to see the big picture.
    An architect must be able to consider the organisation as an entire system. Those who prefer to focus on point solutions or drill down into the detail of one thing at the expense of the rest are not suited to architecture.
  6. A natural preference for simplicity.
    The best architecture is the simplest possible one that can fulfil the business vision. Those who gravitate towards, and enjoy complexity do not make good architects. Those who abhor complexity and take please from finding the simplest possible solution to a problem are the ones you want.
But what about specific business or technical knowledge? For me, it is not specific knowledge that matters, but a demonstrable ability to adapt to new situations, and understand new ways of working, and new enabling technologies at the drop of a hat. Those with specific in-depth knowledge generally measure their own value in terms of the relevance of that knowledge. As a result these people often fear change, as it may negate that value, and thus negate their importance. They are not best placed to view the future from an unbiased point of view. Unfortunately, businesses too often focus on finding people with the specific knowledge to support their current position, and then wonder why these people bring nothing new to the table.

What are the Right Working Practices?
When setting up an EA team, the best working practices are those that will allow you to both engage with projects and continue to build your architecture, without the demands of one impeding progress on the other. You need to quickly establish who will support projects, and who will build architecture, and then you need to ensure that these two groups retain a close working relationship as each will feed the other.

Your working practices need to support a proactive approach where the build activity seeks information regarding the future strategy, (and in turn helps to guide future strategy) and quickly articulates this information as future architecture.

You also need to support a reactive approach that allows the architecture to engage with projects at an early stage and either feed them with information already recorded in the architecture, or re-prioritise build activities to focus on the areas of the architecture that will fulfil the needs of the project.

How Should We Build It?
Build it? That’s the scary bit, isn't it? This brings us to the heart of the problem. So many EA practices spend time avoiding the really important bit because they are frightened of it. I strongly believe this is why so many processes for establishing an EA practice start with a sequence of what I feel are little more that prevaricating steps. In a consultancy led world, an outside “specialist” can use this approach to provide a significant amount of content without actually having to get involved in building anything.

In the early stages you need to recognise that initial demand will come fast, and will come from two sources; above and below. From above, you will need to engage with the business to articulate the future vision in the form of a Business Architecture. From below, in-flight projects will start to demand guidance relating to low level implementation decisions. You will need to have the courage to make some decisions relating to future technologies with very little guiding information, and articulate these decisions in your Technology Architecture. Some of these decisions may turn out to be wrong, and you must be willing to accept this, adapt your Technology Architecture accordingly, and help projects to absorb these changes in a pragmatic manner. Remember, that sometimes the simple act of making a decision and sticking to it is what makes that decision the right one.

(I will cover what goes into an Enterprise Architecture in terms of levelling and content in later posts in this series).

It is this build focused activity that guides your engagement with projects, and more importantly with those who set the vision and strategy of the organisation as a whole (and yes, that does include you as an architect).

And the Rest?
Let’s now return to the original steps that I declared to be the wrong ones. They were:
  1. Identify the fundamental principles that the architecture will support.
  2. Establish the governance framework that will ensure compliance with the architecture.
  3. Establish the architecture framework that the EA practice will adopt.
  4. Start to engage with projects.
Am I suggesting that these are not important, or can be ignored? Of course not, but what I am stating is that these are not the very first things you need to do. Once you are up and running and developing the architecture (and thus hopefully providing some real value) you can address these other areas on an as-needs basis.

Principles can be recorded if you like, but remember that your architects, if properly selected, will already naturally apply sensible principles to everything they do. Do not expect others to act on these principles however. They need you to act on them and provide an architecture that fulfils these principles.

A governance framework will be important as your architecture develops, but you must start in a spirit of cooperation and assistance to win support and credibility. Once this has been established and you have some content in your architecture you can start to introduce more formal governance mechanisms based on this content and the trust you have already established.

An EA framework is also important, but it should be your own, and it should be adapted to and derived from the unique circumstances that exist within your own organisation. Once again, attack this on a just-in-time basis, cherry picking from the various reference frameworks those features and details that you find you have a need for, and always consider carefully whether it really adds value to what you are doing. (Roger sessions wrote a good article on EA framework comparison available for download at http://www.objectwatch.com/whitepapers/4EAComparison.pdf).

Is This the Only Way?
Of course this is not the only way. You are an architect, and you are in charge of your own approach. If you cannot set your own direction of travel, then you need to question whether you can set the direction for others to follow. The intent, however, should always remain the same:
To start producing an Enterprise Architecture and to become a useful addition to the organisation in as short a time as possible.
The longer you take to do this, the more likely it is that someone will decide (correctly) that you are surplus to requirements, before you even get started.

Regards
The Enterprising Architect