â€¢ Flows from strategy.
â€¢ The Zachman Framework provides an example (see later discussion).
â€¢ Can increase or decrease maintenance costs by 25 percent.
Technology architecture normally dictates how systems will be designed
and implemented. It must be consistent with the enterprise architecture,
which is a broader concept. An enterprise architecture describes in various lev-
els of details how the business is designed and functions. One common ap-
proach to enterprise architecture is the Zachman Framework. Zachman divides
this description into five different views, which include an ever-increasing
level of detail. The scope view identifies what will be included in the architec-
ture. The ownersâ€™ view describes the enterprise from how the owners under-
stand it, without technical detail. The designerâ€™s view provides detail on the
relationships required for the ownersâ€™ view to be implemented. The builderâ€™s
view describes how the systems are built and implemented. Finally, the de-
tailed subcontractorâ€™s view shows the very detailed relationships.
The idea behind describing the architecture is to ensure there is one way to
do each process, and each time you approach a new need, you do not create a
stand-alone point solution. Rather, you leverage your existing investment.
This simplifies your environmentâ€”both technology and nontechnologyâ€”and
controls cost. Exhibit 17.1 shows an application architecture for a generic pro-
fessional service firm. Key applications include time entry and tracking, proj-
ect management, billing, financial reporting, document management, sales
tracking and bid management, staffing, and intellectual capital management.
Technical architecture illustrates the technical platforms that the company
operates, the interfaces between these platforms, and the connections to ex-
ternal communication networks. Exhibit 17.2 shows all the categories of tech-
nology in an organization that will eventually make their way into the
companyâ€™s application and technical architecture.
The trouble with teams is that only the lead dog gets a change in scenery.
â€”Donald Walker, Sergeant Preston of the Yukon,
from Never Try to Teach a Pig to Sing
An IT organization must ref lect the business. Typically, an organizational
chart starts with the chief information officer or IT director and cascades
from there. An example is shown in Exhibit 17.3. This is a traditional approach
and would certainly allow someone to determine whose reporting structure
communications Sales Delivery Recruiting Accounting IT Productivity
Candidate/ General Help desk MS Office
Resume ledger tool Word
Accounts IT asset
Internal payable management
intranet Sales orders Organizational
Accounts IT knowledge
Internal receivable base
Lead sharing Visio
Time and Phone/VM
expense tracking tool
EZ access Project
IC/Knowledge Project IT project
module MS project
management/ accounting tracking
Engage management Firewall
Fee schedules Employee
Project date New hires/
Task CapEx Company
distribution equipment address book
Reprinted with permission, Executives Guide to Information Technology.
Exhibit 17.1 Application Architecture for a Generic Professional Service Firm
any IT person fell within. Typically the organization is bifurcated by applica-
tions and the infrastructure (i.e., operations) groups. The applications man-
agement group is responsible for the performance of all the teams in the
application development and support group. The application manager must
have a complete understanding of the business systems used in each area of
the business. The operations manager is responsible for the performance of
all the teams in the IT operations group. The operations manager must have a
basic understanding of the technologies used in each of the areas managed.
438 The Back Office: Efficient Firm Operations
Computing hardware servers Desktops
Network attached storage (SAN)
Appliation software Pachage software (EAP, CRM, other point-solutions)
Custom developed software
Systems software Operating systems
System performance management
Development Development languages
Database design standards (normalization rules)
Intrastructure and facilities Cabling
Equipment storage (racks/shelves)
Media burner (CDRWXXXX)
Outside services Consulting (by application/technology area)
Exhibit 17.2 Sample Technology Inventory
Manager Operations and Manager Applications
â€¢ Tier 3 application support
â€¢ Tier 1 support Application Development
Help Desk Manager â€¢ Application development
â€¢ Central contact point for Manager(s) â€¢ Application deployment
â€¢ Help Desk Analysts â€¢ Programmers/Development Teams
â€¢ Application testing
â€¢ Tier 2 support
End-User Support Application Testing
â€¢ Application deployment
â€¢ On-site problem resolution
â€¢ PC/desktop support and
â€¢ Break/Fix Teams â€¢ Testing Teams
â€¢ Database design, installation
â€¢ Tier 3 network support and configuration
Senior Network Database Administrator
â€¢ Data network problem â€¢ Database monitoring
resolution â€¢ Data integrity and backup
â€¢ Data network administration
â€¢ Junior Network Administrators â€¢ Junior Database Administrators
â€¢ Data transfers between
â€¢ Tier 3 system support
Senior System EDI/Application Interface
â€¢ Server problem resolution
â€¢ Data synchronization across
â€¢ Server support and
â€¢ Junior System Administrators â€¢ Junior Interface Specialists
â€¢ Business user relationship
â€¢ Tier 3 telecom support â€¢ Requirement gathering
â€¢ Voice network problem Senior Business Analyst â€¢ Requirement programming
â€¢ Voice network administration â€¢ Business user application training
â€¢ Telecom Analysts â€¢ Junior Business Analysts
Exhibit 17.3 Standard IT Department Organization Chart
440 The Back Office: Efficient Firm Operations
When organizing a department we follow some general rules of thumb
that we will share with you:
â€¢ Separate application and operations.
â€¢ When possible, hire good managers to oversee each group.
â€¢ Do not allow individuals to f loat around the organization in odd roles
that donâ€™t report up through the two main lines (i.e., no f loating boxes).
When the organization chart must start ref lecting personnel with f loat-
ing boxes, chances are there is something dysfunctional occurring.
â€¢ Develop growth ratios for each position so that senior leadership can
determine the proper headcount to assign to the group over time.
â€¢ Develop consistent titles and roles/responsibilities. Each person/
position should have a concise and clear one-page role description with
quarterly or annual management objectives.
Another approach is to create a chart that indicates how the IT organiza-
tion is structured to address user needs. While this type of chart is not as in-
tuitive to read, a very brief textual description can accompany it and will
provide users a better understanding of how the organizational structure is
designed to support them. Describing the organization in this way can also
help ensure efficient operations. A functional view of the organization will
show where redundancies exist.
For multioffice professional services firms, IT department organization
can become somewhat challenging. Should each office have a dedicated IT
support person? Can local IT support purchase hardware or must that be ac-
complished at the headquarters? If the local office needs call for the addi-
tion of a server, must that server match the corporate standard? In general,
most firms will want centralized management and control of IT support and
purchasing decisions to ensure economies of scale and standardization of the
environment to minimize support cost. Additionally, any office with more
than 30 employees will typically need a dedicated IT support person. Of-
fices under this size can manage via a local part-time or contract support re-
source. Most duties today can also be managed remotely by the corporate
support team. Exhibit 17.4 shows how the staffing of the IT organization
might change over time with the growth of the firm.