There are a number of critical technical domains in an Enterprise Architecture. At the top most level, you can define Enterprise Architecture as:
- Application Architecture
- Security Architecture
- Technology or Infrastructure Architecture
- Business Architecture
In the Application Architecture domain, I consider the following key sub-domains:
- Business Intelligence and Data Architecture
- Web and Portal Architecture
- Integration Architecture and Service Oriented Architecture
- Application Security Architecture
Now of course these four domains relate to each other more as a Venn diagram than anything else. Articulated in a different way, you need to continually consider all of these domains working in unison not as separate entities. The other outcome of looking at Application Architecture in these four domains is that the majority of activities fit into one of the four so it is a fairly comprehensive framework.
The leadership structure of these four domains need to be constructed in a way that promotes collaboration and solidarity. Specifically if you divide ownership of these domains across a leadership team, you need to ensure that those selected are people who embody a teamwork mentality and understand that you will all succeed together and problems will arise if one of the leaders is working by themselves in a silo. This may sounds obvious but it is always good to remind yourself that the best architecture strategy, reference architectures, etc. will not allow you to meet your business objectives without the correct leadership team.
Delving into these four domains in a bit more detail...
The BI & Data Architecture domain is focused on providing the business with the correct intelligence, reporting and analytics to make the best possible business decisions. The best reporting tools without accurate data are worthless hence the need to look at BI and Data together. Data is always tricky because it is never 100% accurate - it's an on-going effort to cleanse, define, govern and it never ends, Companies are prone to fall into the trap of designing very complex BI strategies that do not return business value for many quarters or sometimes years which leads to disastrous results. As an IT organization you must be able to show quarterly improvements which the business can see and feel so make certain that the IT portfolio is a balance of back-end improvements AND front-end improvements. Be especially pragmatic in the BI domain otherwise the business will devise their own reporting solutions which in the short-term help meet the immediate business need but in the long-term create an architectural mess that will take a substantial amount of time to clean up.
The Web & Portal Architecture domain is focused on "all things rendered" so it includes any visualization of content, data or workflow. Tangibly this would be a web site, portal, mobile device, dashboard, etc. The IT organization should provide the business team with one consistent platform that supplies the common capabilities required by any of the business functions. Examples include Enterprise Search, Content Management, Portal, Web2.0 including wikis, blogs, communities, etc. Each business function will leverage these common capabilities is a slightly different way but each function (Marketing, Sales, Manufacturing, Service, Finance, Legal, HR) needs these common capabilities. By creating a single common platform, the business benefits include:
- More consistent customer, partner and employee interface
- Greater agility in terms of providing these common capabilities
- Ability to focus resources on truly differentiating capabilities
- Lower operational costs and simplified trouble-shooting
The Integration Architecture and SOA domain is focused on all connections and integrations across systems and processes, both internal and external. By analyzing Integration Architecture you inherently need to analyze business process. In most companies you will find opportunities to simplify Integration Architecture but not without simplifying business process. For example if there are numerous ways for your eco-system of partners to send information or transact business, the ability to simplify or standardize that integration may also require a change in business process. If your business acquires companies, the ease at which you can integrate the acquired company is directly proportional to how solid your Integration Architecture is. Acquisition integration typically require business process change as tools and systems change.
SOA is of course a much broader topic that deserves more time than I will give in this post. Suffice to say that IT should look at every capability that they provide as a service. The architecture and design therefore should be a loosely-coupled one with the ability to leverage the service in an agnostic way. Ask the question "can any business function leverage this service or am I architecting to meet the needs of only one constituent?". Designing capabilities as a true service is not something that everyone has the skills to do - make sure you have the correct resources who have the correct mind-set as well as experience in designing an SOA.
SOA governance is critical in terms of who is going to maintain those services, who can leverage those services, who will build those services as well as what the operational aspect of services such as usage, trouble-shooting, testing, etc.
The Application Security Architecture domain focuses on access control throughout the application architecture. Both internal (employees) and external (partners, customers) should be considered when designing the Application Security Architecture. Most people refer to this as Identity and Access Management but you must look much broader to ensure that you are creating an architecture that will meet the variety of needs in this space. Normally people look at their web interfaces and application interfaces when considering security - who should or should not have access, the ability to provide or remove access, password management, etc. You also need to consider data security - how will you provide the correct data to the appropriate people. Data security can be managed at some level through the applications but you need to understand how granular your data security needs to be. For example, think about your sales force and how you will provide the different sales people (Account Managers, District Account Managers, VPs, Directors, Distribution Account Managers, etc) the correct data by account, lead, geography, product segment, etc. Also consider internal vs external users. Think about Contract Manufacturers and Channel Partners - what data will they have access to? Finally do not forget your Integration Architecture when it comes to security. Think about who/what can access your web services and B2B systems.