Having defined the channel(s) through which a business will sell its products, a Business Architecture must also specify how products will be serviced. No organisation can afford to abandon customers after a sale without considering product support and servicing. As with the point-of-sale IT capabilities, servicing has its own set of requirements, e.g. if done through a call centre it will likely require advanced telephony capability such as automated caller identification, interactive voice response (IVR), etc. If servicing is planned at branches, technology will need to be available at those counters, which in turn requires appropriate network capabilities such as a wide area network (WAN). If servicing will be carried out by field workers, there might be a need and strategy for mobile computing so that agents can access sytems from a mobile device.
Another item that the Business Architecture must define is the range of products that the business will manufacture or sell. In industries such as Financial and Banking, the administration of products rely heavily on IT and it is therefore important that clear strategies exist around products and platforms to administer them. Not only must a roadmap exist for the platform(s), but also whether off-the-shelf software will be used as opposed to in-house developed. For both of these options the roadmap must show how and when software will be reviewed and how its lifecycle will be managed when a product range is expanded or when a product range is coming to its end.
We said that a Business Architecture needs to convey information that will determine key aspects of the IT landscape required to support the business. So now, in practical terms, what detail can be found in a Business Architecture? In the next posts I will share some xamples. First example: It needs to state how products will be sold and distributed. If it is a telesales business, it will require an outbound call centre, which very likely requires specialised telephony capability including automated call distribution (ACD) and predictive dialling. If it will involve sales agents, the operation might require point-of-sale capabilities such as laptop-based software that the agent can use to sell and promote products in the field. These technologies need to be planned for and it needs to be clear which parts will be bought and which parts developed in-house.
Business Architects naturally play a key role in the Enterprise Architecture activities. I say “naturally” because EA cannot exist without Business Architecture. It is therefore often a surprise to hear that an organisation’s Business Architects are in fact not part of the EA team, but function in another department, such as Product Development. I would welcome comments on how Business Architects are placed in your organisation and whether they are part of the EA team.
The accompanying diagram is an example of what a conceptual business model might look like. As can be seen, focus is on the major activities of the business and the groups of people that play a role in running it.
If we return to the Business “layer” of an EA framework with more practical focus, I will suggest some content for a Business Architecture, e.g. what topics are typically addressed and what a Business operating model might look like.
The following are typical topics for the Business Architecture of a financial services organisation: Mission, business objectives, types or groups of clients targeted, the relationship that is desired with these clients, product types to focus on, distribution channels to be adopted, specific financial targets for a year or more and perhaps statement(s) about the brand to be promoted for the company.
Here’s another interesting view by Gartner of how Information Architecture fits within the context of Enterprise Architecture. In the accompanying diagram (which depicts EA) the shaded area in column 2 shows the scope of Information Architecture. Note how the word “business” features in this diagram – especially where the application architecture is concerned.
In my September blogs I will present examples of practical implementations of the frameworks we theorised about. No use in wallowing in theory for too long – practical application is what it’s all about!
Why is it worth practising EA and what is the Return on Investment? One could argue that the ROI all comes from Information and its use, so it could be a Return on Information. Firstly, if the architecture (current) is documented, it is easier for people to find information. For example, if an audit is required of all application software, the information will be readily available. In my (large) organisation the Application Architecture is reasonably well documented and it was easy to provide our new outsourcer the information to support our applications. Secondly, if the organisation wants to promote re-use of processes, applications, data and infrastructure items, it needs to have these inventorised with views that can be understood by business as well as IT development staff.
I previously discussed EA Frameworks and some readers might be wondering about the terms “framework”, “process” and “methodology” and possible overlaps between these. Looking more closely, the Zachman Framework is very useful to apply a taxonomy when describing a current or future EA. The TOGAF is very useful when deciding on an EA Process or Method (remember the Architecture Development Method within TOGAF?). Lastly Gartner offers their EA Methodology – useful when looking for a Method to use for the Practising of EA. So these are different concepts, but should be combined in an EA effort to increase the chances of success.
TOGAF’s ADM consists of the following stages:
– Preliminary phase (deciding the framework to be used and principles, getting commitment, planning)
– Architecture Development (vision, Business architecture, Systems architecture, Technology architecture)
– Business Transformation planning (solution opportunities and options, migration planning)
– Architecture Deployment (governing the implementation)
– Architecture Realisation (managing change)