Skip to main content

Critical Pillars of Enterprise Architecture

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.


Comments

Popular posts from this blog

6 Key Steps to a Successful Mobile Apps Strategy

What IT Can Do to Lead a Successful Mobile App Strategy CIO’s are under pressure to deliver business capabilities on mobile devices, all while optimizing budgets, increasing operational excellence, and providing innovative, secure solutions. It’s a complex juggling act. In the mobile space, it’s tempting to just jump in and start building mobile apps. But corporate IT needs to help balance the exuberance of building apps with using a common set of success criteria. This is especially true if the enterprise wants a manageable and successful mobile app effort, defined by usage, adoption and business value. While corporate IT can provide technical design and architecture expertise, even more important is the role they play in terms of coordinating the enterprise mobile app strategy. Here are six key steps for doing so: 1. Create a cross-functional “mobile app working team” This is a group of business and IT team members that are passionate about creating mobile solutions

The End of Solitude - Response to William Deresiewicz

I recently read an article by William Deresiewicz titled “ The End of Solitude ”. What prompted me to read the article was an interview with Mr. Deresiewicz that I heard on NPR. During the NPR interview, Mr. Deresiewicz delved into the importance of solitude, being alone and time for self-reflection. Of course, you are naturally drawn to premises that are similar to your own so I listened intently as he contrasted the present with the past regarding the lack of “alone” time that we all face today. Mr. Deresiewicz’s literary knowledge is beyond impressive – he’s an academic and is able to compare and contrast numerous thought-leaders of the past and their views of the value of solitude. In “The End of Solitude” he highlights the importance of solitude that numerous philosophers and famous authors have written about for many, many years. My personal appreciation for Thoreau’s writing, specifically Walden and more specifically “Solitude” and “Economy” immediately came to mind as I read

Quadrennial Energy Review - Jan 2017 (notes)

https://energy.gov/sites/prod/files/2017/01/f34/Transforming%20the%20Nation%27s%20Electricity%20System-The%20Second%20Installment%20of%20the%20Quadrennial%20Energy%20Review--%20Full%20Report.pdf "The electricity system we have today was developed over more than a century and includes thousands of generating plants, hundreds of thousands of miles of transmission lines, distribution systems serving hundreds of millions of customers, a growing number of distributed energy resources, and billions of enduse devices and appliances. These elements are connected together to form a complex system of systems." "The electricity sector is, however, confronting a complex set of changes and challenges, including: aging infrastructure; a changing generation mix; growing penetration of variable generation; low and in some cases negative load growth; climate change; increased physical and cybersecurity risks; and in some regions widespread adoption of distributed energy resources