Understanding Enterprise Architecture

Introduction

The term "Enterprise Architecture" has multiple meanings. From a design/IT perspective, it's the process of capturing an organization's enterprise level business processes in the architecture of a system. Secondly, from a business perspective, it can be thought of as a current snapshot of an organization's existing IT infrastructure, business functions or processes, it's communication mechanisms and how data/information is shared throughout the organization. The function then, of an "Enterprise Architect" is to analyze the latter and use this information to implement or improve the former.

Technically Incorrect

The majority of IT professionals today include this term in their resume in reference to a particular web application, component or database solution, without ever taking the time to consider how the web application or component they are developing truly impacts the enterprise level organization for which it is being designed. This doesn't mean their contribution isn't enterprise worthy, but it does beg the question of how many of these individuals really understand what's involved in an enterprise project. There's really no mystery here as to why either. It's unfortunate that, in most cases, programmers aren't provided with the bigger picture so they don't have a clear understanding of what constitutes an Enterprise application or solution. In many cases, the tools they use for development, include so many extras that their assumption is, if they've written a certain application using a particular framework, they must be designing an enterprise level application or component. Keeping it simple has definitely gone out the window in a lot of cases, especially when one considers that in most cases all this extra infrastructure is really unnecessary, especially when you're designing a simple information website for a friend. And no, just because you hooked DRUPAL to a backend MySQL server (case in point - this website) it's not an enterprise level web application. And then of course there are all the websites out there that teach or provide you with code snippets in for JEE or .NET SOA style programming or show you how to design your app or component using UML and other "enterprise" tidbits. They walk you thru the creation of an EJB or a .NET web service, demonstrate the deployment to whatever flavour of application server you're using and even discuss such things are clustering, mirroring and disaster recovery. Unfortunately though, they don't spend a whole lot of time discussing the bigger picture of how this fits into the needs of the enterprise. But hey, they're talking about creating EJB's, so this must be enterprise level architecture type stuff right?

Asking Yourself the question: "Why?"

Enterprise Architecture is about a whole lot more than simply creating a bunch of web applications, web services and/or databases. One needs to understand WHY it is that these applications or components have been put together the way they have, and not just focus on the building blocks. Understanding what drives the business is equally, if not more important. In discussions with most developers about customer relationship management (CRM), they can usually cite a list of examples. The same holds true with regards to image scanning and document/photo management systems. The problem is, they can't tell you WHY they're important. They don't understand the underlying business processes and rules driving the use of these types of tools. One needs to take several steps back from the planning table and begin to study these business processes and rules. An organization isn't comprised of merely one person or department in an organization, but rather the sum of all the collective parts. In the same way, the Enterprise Architecture isn't merely a bunch of web apps and components thrown together without purpose, but rather involve the careful consideration of how such tools help with the interaction between people, departments and business units.

High Level Thinking

I'm a programmer, so yes, I'm often faced with the difficult task of separating my technical thinking from the business perspective. At the top level, the Enterprise Architecture consists of the business processes and rules that permit the interaction and sharing of data/information between departments, individuals and business units. It doesn't matter whether the enterprise is non-profit, not-for-profit or for-profit. In all cases information exchange is key. This, together with the insurance of Business Continuity despite undesired interruptions, are the keys to success.

Business Process Analysis

The first step in understanding an organization's business function, and therefore what type of solutions can be implemented, is to understand it's business processes. Departments and individuals share information and/or data in a number of ways including:

• telephone
• emails
• documents or memos
• instant messaging
• presentations
• demos
• blogging (i.e. twitter, wordpress)
• publications or newsletters
• web portals

It's important to understand the driving force behind these different modes of sharing information and identifying the implications of each type of sharing mechanism. Many considerations are necessary as follows:

• security or sensitivity of information (intellectual property, customer privacy, etc.)
• easy access
• ease of collaboration within a group/team setting
• data access or change tracking
• time sensitivity of data

These considerations are important in understanding the different business processes and rules that departments, individuals or business units implement and adhere to. Another aspect is workflow. This is the routing of data or information between departments, individuals or business units for the purpose of completing a business objective. A very common and simple example is the Human Resources resume workflow:

1. A resume is received via email/fax/mail, scanned where appropriate and added to the company's DMS (document management system)
2. The HR Manager delegates work to HR personnel to filter and remove unqualified resumes from the system, processing qualified resumes by skills matrix and making these searchable on the company's intranet.
3. The HR Manager searches for qualified applicants, sending them to the HR Manager for scheduling of interviews.
4. Initial interviews are held over the phone to pre-screen applicants based on department needs and this is fed back to the department manager.
5. HR Manager receives back a narrowed down list of applicants for 2nd interview, and schedules each one - reviewing online calendaring system to ensure schedule of applicant and department manager are acceptable.
6. Department Manager and/or subordinates meets with each candidate and narrowing down the candidate list until finally choosing a winning candidate. This information is sent back to the HR Manager.
7. HR Manager contacts candidate and negotiates salary and benefits
8. Upon acceptance by candidate, HR Manager creates a new entry in the employee system for candidate and information Payroll.
9. etc...

Wait! Did I say simple? I meant super COMPLEX. And this is just a resume workflow. I didn't include any of the steps payroll and HR have to go through to get the person hired, into a cubicle, using a computer, etc.

Business Continuity

Most developers understand some of the basic concepts behind continuity planning. More senior developers have probably been burned by, and therefore understand why source code control systems are so crucial to software development. The same is true for the enterprise. A critical component in an organization's enterprise architecture, is it's continuity during times of disaster. Disaster recovery is often an after thought, but without a proper DR plan during the planning phase, the interruption of business is a very real possibility.

Business Practices

In order to understand an organization's business, it is necessary to dissect the business into various practices or disciplines. The organizational goals, which include such things as the mission statement, are important because they are meant to provide the "guiding light" for the organization. An organization's operating model is essentially the high level blueprint showing the bridging between the business and it's adapted technology. ITIL (Infomration Technology Infrastructure Library) is becoming one of the standard operating models being adopted by many of today's organizations. The organizational model, which describes the breakdown of the company into business units, with operational boundaries, is also important to understand. This can give an architect insight into the communications required and/or gaps which need to be bridged in order for the organization to successfully function.

Business Processes

Business processes are at the heart of every organization. Goverened by a set of business rules, they are the functional highway that the organization uses to be profitable. Business processes are included in every operational area of an organization including:

• project management
• research and development
• quality control
• product delivery
• billing and accounts receivable
• finance and accounts payable
• human resources/payroll
• accounting
• operations
• technology and infrastructure
• procurement
• inventory and warehousing
• customer service/support
• warranty servicing/RMA
• sales and business communications

Each of these operational units requires information both internally and externally in order to properly function within the organization:

• Project management has no useful function without the RFQs, RFPs and eventual work generated through the sales process
• clientèle would not provide repeat business without the assistance of customer service, which would be unable to perform it's job without technology and infrastructure such as telephones, a webste and email
• warranty service can not function without inventory and serves no useful purpose without warranty work/RMAs generated through customer service requests

Business Information

Business information/data is a key component to successful business process execution. Information is routed between individuals, departments, business units and management. This information is used for every level of decision making, without which, business processes would halt and/or break down. The sample given earlier was a simple resume routing process. Even this simpe example included many rules, stakeholders, actions, states and boundaries of responsibility. In order to properly track and route information/data, it is necessary to create logical and eventually physical data models which illustrate and tie together information in a meaningful way. As an example:

• An organization has many employees
• Each employee has both personal and professional information (i.e. salary, start date, employee number)
• Payroll must keep a record of each pay period per employee, including total salary earned YTD, and for the period, total deductions, contributions, etc.
• Each employee belongs to a department within the organization
• Each employee will work on many projects during his tenure
• Each project has multiple employees and must manage their workload

This example illustrates the logical associations between organizations, employees, payroll and projects. These are but a few of the relationships within an organization. Each relationship has a number of data points (i.e. yearly salary, birthdate, name, etc.). A logical data model must be created that attempts to link the relationships and documents the data points/attributes of each. Logical data models reflect the business information and not necessarily the technical level details. As an example, a project manager within an organization's Canadian services branch is paid $100 CDN per year (this is business information). At a technical level, this may require currency conversion (with history tracking) if the organization's payroll department processes salaries in US funds.

(...to be continued...)