This week we discussed E-Business Architectures, a topic of personal interest to me as an Enterprise Architect!
The first principle we covered was the divide and conquer approach to IT. Really anything can be broken up from a conceptual idea, into a group of logical units, that are realised at a physical level. Of course, this really describes the high level principles of Enterprise Architecture!
For me, I like the 12+1 view of Enterprise Architecture which is as follows:
- Contexual – this is the layer that defines business strategies, purpose, outcomes etc. Why an organisation exists.
- Conceptual – this is the layer that senior managers operate at, and describes the highest level components within an organisation, like business units, organisational data models, and generic technologies like CRMs and ERPs.
- Logical – a further breakdown into supporting functions. From a business perspective, talking about business processes. From a technology layer, talking about a particular component such as an Application Server.
- Physical – the realisation of the logical layers. Think of it as the concrete version of the logical layer. So processes are realised as procedures and work files. The logical view of Application Servers gets realised as an installed bit of software on one or more literal servers, deployed to a literal data centre.
The conceptual, logical and physical layers, are sliced into business, information, application, and technology towers, thereby creating a 12 box matrix, with the +1 being the contexual layer.
Anyways, we then moved onto Service Oriented Architecture, the core characteristics of this was a group of services loosely coupled, which can be combined into a complex process. The advantage of SOA is that any particular service could be replaced by another service without materially changing the rest of the business process. These services could be delivered by both internal and external entities. A good example of a service would be an address lookup service. This could be created internally initially based on an internal database. Or it could be a web service provided by NZ Post.
So a business process could be a customer joins an energy company. For this to happen, customers need to be quoted a price and product. But for this to happen their address needs to be provided. So once an address is provided by the customer, this information can be provided to an address verification service, which I view as a technical service. Once this is returned, we can call the quoting service, which in turn can call the product technical service, which itself calls the pricing service. These collection of loosely coupled services are aggregated into business services, i.e. the customer join service.
We talked about some of the technical methods around SOA, like WSDLs to describe web services, SOAP on the formatting of those messages, and UDDI to discover services, but all of that stuff just wasn’t adopted in reality from my perspective, because of the complexity of all of those integration methods. These days, REST+JSON seems to be the easiest way to integrate services, especially for modern web applications.
We then talked about Enterprise Architecture Frameworks, a topic of interest to me! We looked at the Zachman Framework which is an ontology, or a way of categorising things, like servers, and applications, and business functions. Zachman doesn’t describe how to use the ontology, it just provides one. TOGAF (of which I’m certified!) describes a method of doing Enterprise Architecture, but doesn’t really describe outputs. If you add Zachman and TOGAF together, you’ll end up with something that’s practical, which in my opinion is the Integrated Architecture Framework.
Finally, we looked at ITIL, specifically thinking about the impact on SOA management and governance. ITIL specifically talks about the lifecycle of services, such as service strategy, design, transition, operation, and continual service improvement. Though in practice, I’ve only really seen Service Operation in use in organisations, typically Service Desk, Incident Management, Problem Management, sometimes Capacity Management etc.
However, full ITIL could be used to think about the business value of services, who are the stakeholders of the service, how they define value, and how the service (made up of more technical services) realises the business outcomes of the stakeholders. But in practice, I haven’t seen this in my 13 years in IT in New Zealand.