46 IT Pro January/February 2010 P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 1520-9202/10/$25.00 © 2010 IEEE

EntErprisE ArchitEcturE

Waleed NemaSaudi Aramco

The author’s simple model for an information services architecture is intended as a common frame of reference for both business and technical practitioners and groups various aspects of computing into four distinct layers based on data processing stages

T he term enterprise architecture (EA) ema-natedfromITandisstill largelywithinits realms, indicating relianceon ITononehandandtheneedtocloselyassoci-

ateitwithenterprise(business)ontheother.WhenITarchitectsfaceplanningtasks,theymustdem-onstratehowtheirtechnicalplanbestservesthecorporateone. Indoingso, theyhave toaddressmyriad technologies that can frequently confusebusinesspeople,whomustunderstand,approve,support,andsell the technicalplans tomanage-mentandothers.Bridgingthisdividerequirescre-atingasimplified,mutuallyunderstandablerefer-ence model.

Simplification allows business and technicalpractitionerstosharethesamelanguageandframeof reference. Developing any field of science de-pendsonhavingacommonlanguage(suchasmathsymbols formathematicians) to facilitatecommu-nication. Business people should be comfortable

with the terms technicalpeopleuseso thatbusi-nessmanagementcanpromotetechnicalconceptsthemselves and propagate consensus and excite-ment at all levels of an organizational hierarchy.Theabilitytoabstractdetailstoahigherconceptuallevelisanotherrequirementthatlevelsoutunder-standingamongpeopleandanchorsinterpretationsto already familiar concepts. A successful modelmusthaveaclearthemeandclassificationscheme.Dividingtechnologiesintomutuallyexclusiveandfamiliarcategorieshelpspeopleinternalizeandsellthemodeltoothers.Onceaproposedmodelmeetsthesecriteria,itshouldbecomemoreeasilyaccept-able as a standard. (See the sections “StandardsFuelGrowthandCreateJobs”and“StandardsIn-creaseCreativity”elsewhere.1)

A New ModelMy proposed model fulfills these requirementswith fourmutuallyexclusive layersclassifiedac-

An Information Services Architecture Model Based on Data Processing Stages

computer.org/ITPro 4 7

cordingtodataprocessinglifecyclestatesorstag-estowhichbothbusinessandtechnicalpeoplecanrelate:operations,data,information,andservices(ODIS).Ibasedthisclassificationontheprocess-ing stages data goes through from acquisitiontoconsumption—thatis,dataisfirstgenerated,thenstoredandmanaged,andthenfinallytrans-formedintousablebusinessinformation,foruseasservices.

I mapped the data processing classificationschemeagainstknownEAcomponentsforfur-thercommonality.The fourabstraction layersaresimilartothosepresentedinthesystemic en-terprise architecture methods(SEAM)orobject-ori-entedmethodsinenterpriseengineering,suchastheISOReferenceModelforOpenDistrib-utedProcessing.Thelayersareconsistentwiththe Open Group Architecture Framework’snine layersand theUSFederalEnterpriseAr-chitecture Framework architectural segments.The model’s classifying layers or perspectivesthat cross horizontally through all enterprisebusinessunitsarethesameasthosepresentedin the section “Enterprise Information Archi-tectures—The Horizontal Approach,”1 whichisbasedonJohnZachman’sframework.2Iex-plainthefourlayersinthefollowingsections.

The ODIS ModelI created the model to simplify and create acommon business language and single frameofreference;eachlayerrepresentsahorizontalperspective into all systems and focuses onlyonitsparticularaspectofcomputing.Thedata layer(DL),forinstance,focusesondataqualityregardlessofthesystemordatasource,where-astheservices layer (SL) isconcernedwiththebusiness story (that is, emphasizing businessneeds in nontechnical terms) regardless ofhow many IT systems must integrate to pro-videit.

In broad terms, we can view the four layersas“dataprocessingforpeople,”wheretheSListhepeopleaspect,themiddletwolayersarethedata aspect, and the operations layer (OL) is theprocessing aspect. Figure 1 shows the model’staxonomy.

BeforeIgetintomodeldetails,notethatcon-ceptualmodelsandframeworksarereallytoolstocreateanarchitecture—they’renottheactualarchitecturalplanitself.Architectsmuststillcre-

atethelatterusingtheframeworktoproduceaspecificblueprintthatabuildercanunderstandandimplement.

Let’s now look at each layer, how it maps toEA,andthetechnologiesandconcernswewouldencounter.

OperationsAttheOL,usersgeneratedataviasoftwareap-plicationsaspartof conductingbusiness.Thislayerincludestransactionalactionsandauthor-ingoreditingactions.Itrepresentsthefunctional view—thatis,theaspectofcomputingatthecoreof IT.This layer isequivalent to the functioning enterpriseorfunctioning perspectiveintheZachmanframework2 or the functional or business pro-cessviewinotherframeworks.Itrealizesseveralhigher-levelconceptualizations.

EA mapping. Youtypicallymapthis layer intotwo sublayers: the applications architecture (AA)andthetechnology architecture(TA).TheTApro-vides thecomputing infrastructure for theAA,whichgeneratesthedata.

Technologies. The AA sublayer includes sev-eral applications, such as enterprise resourceplanning, geographic information systems,customerrelationshipmanagement,andofficeproductivity suites (documents, spreadsheets,presentations, and so on). Most importantat this sublayer are common services that allapplications need. Examples include direc-toryservices,identitymanagement,andservice-orientedarchitectureservices,includingservic-esdirectories,workflow,andmonitoring.

At the TA sublayer, the computer operationsunit maintains and monitors all systems sup-portinginfrastructureservices.

We can view the four layers as ‘data processing for people,’ where the services layer is the people aspect, the middle two layers are the data aspect, and the operations layer is the processing aspect.

48 IT Pro January/February 2010

EntErprisE ArchitEcturE

Concerns. Availability, scalability, and perfor-mancearekeyrequirementsforthislayer.

DataThe DL stores and manages data that the OLgenerates—that is, the DL represents data atrest,whereastheOLrepresentsdatainmotion.Weclassifyrawdatastoredinthislayeraseither

structured,asindatabases,orunstructured,suchasemail,documents,andmediafiles.

EA mapping. DLmapsdirectly totheenterprisedataarchitecture,whichistypicallyresponsiblefordataquality,classification,archivingstrategies,rep-lication,metadatastrategies,masterdatamanage-ment(MDM),modeling,andschemaarchitecture.

Publish1. Security classification2. Standard metadata categories3. Time stamp/archiving4. Workflow approval

Tools:• Search• Collaboration• Unified communication• Social networks/tagging

Methods:• Portal (personal/role-based)• Push (email, workflow, alerts, subscription)• Normal computer application

Targets: Mobile (SMS, VOIP, App), browser (internal/external), terminal, IVR

Consolidateand transform

ODIS Information Services Architecture Model

Services

Information

Data

Operations

Infra

Apps

Tech

arch

App

arch

Infro

mat

ion

arch

itect

ure

Data

arc

hite

ctur

eBu

sine

ss a

rchi

tect

ure

Ente

rpris

e ar

chite

ctur

e

Gene

rate

dat

aM

anag

e da

taTr

ansf

orm

tobu

sine

ss d

ata

Deliv

er/u

seda

ta

Clas

sific

atio

n sc

hem

e: d

ata

proc

essi

ng s

tage

s

BI (business intelligence)

OLAP(data warehouse)

Publishedcontent (portal)

OLTP(database)

DMS(documents,

email, media)

Structured Unstructured

GIS CRM ERP Office suite BPM E-learning

Infrastructure

Common app servicesIdentity management (IDM), service-oriented architecture (SOA), integration

Figure 1. ODIS information services architecture model. The model groups technologies into operations, data, information, and services layers and maps them against a known enterprise architecture model.

computer.org/ITPro 4 9

Technologies. This layer includes varioustechnologies, including MDM, data hubs,modeling and schema architecture, replica-tion, integration (near-real-time and lagged),andarchiving.

Concerns. Atthislayer,dataarchitectsmusttakeinto account storage policies for unstructureddata.Suchpolicies includewhat to storewhere(localfilesystem,fileserver,documentmanage-mentsystem,orportal).Datastandards,qualityassurance, and control are also important con-cerns that data architects must address at thislayerwithadequategovernance.

InformationAtthe informationlayer (IL),rawdata is trans-formed into meaningful, usable business data,althoughonlyafterpractitionersapplysomeformofbusinessrulestoitaccordingtostandardsin-formationarchitectshavedefined.Onthestruc-turedside,businessrulesareequivalenttodataconsolidation and transformation; on the un-structured side, they’re equivalent to publishedcontent.Ataminimum,publishedcontentmustundergo security (confidentiality) classification,metadata categorization, time stamping, andworkflowapproval.Nounstructureddatashouldbeconsideredbusinesscritical(thatis,includedfordisasterrecovery)unlessthedatameetsthesefourconditions.

EA mapping. Thislayerisinterestinginthatitinvolvestwotypesofarchitectures.Thebusinessarchitecturedeterminesthe“what”ofinforma-tion needs, whereas the information architec-turedealswith the“how”ofnotonlybringingthedatatogetherbutalsodeliveringitasusefulservices.

Technologies. Aswegoup in the stack,moretechnologies and activity are involved becausemultiplesystemsanddatasourcesareconverg-ing toprovidebusinessanswers.This layer in-cludes several technologies: data warehousing(including cleansing and transforming), busi-nessreporting,corporateperformancemanage-ment,documentmanagementsystems,personaland role-baseddashboards andportals, corpo-rate portals, enterprise content management,andarchivingpolicies.

Concerns. TheILfacesseveralchallenges.Dataquality is the top concern—if garbage-in, gar-bage-out applies, preceding or subsequent pro-cessingisuseless.Dataqualitykeyperformanceindicatorsreceiveamazinglylittleattention.

Metadataclassificationisanotherchallengingglobalproblem.Ataminimum, itmust includesecurity classification. Organizations seldomcreatestandardizedbusiness-specificcategories,letaloneuseorenforcethem.

Keepingupdatedcontent,showingthelastup-dateorreviewdate,andarchivingstrategiesaread hoc processes for numerous organizations.Finally,organizationsmuststandardizeandfol-lowworkflowstrategiesforpublishingunstruc-turedcontent.

ServicesTheSLrepresentsthefruitsofcomputing.Itshouldeffectivelydelivertothebusinesstrustworthy,in-tegratedanswerstobusinessquestions.Thebusi-nessusershouldbeallowedtoreactinrealtimetotakecorrectiveactionorpausenewbusiness-rulehypotheses. This is the layer that distinguishestechnologistsandorganizations,showingwhocanpull it all together and adapt quickly as needed.TheSListheculminationofallcomputing.

EA mapping. Primarily, the SL maps to thebusiness architecture, which is responsible fordeclaring various business scenarios, services,andneededinformation.Informationarchitectstranslatespecificationsfrombusinessarchitectsinto technical terms that they communicatedownstreamforrealization.

Technologies. Wedefineservicesassimply in-formationplusdelivery.SublayerswithintheSLdefinetargets,methods,andtools.

Targets define target devices to which sys-temsshoulddeliverinformation.Targetsincludetypicalterminals,suchascomputerapplications,interactive voice response systems, and mobile

Published content must undergo security classification, metadata categorization, time stamping, and workflow approval.

50 IT Pro January/February 2010

EntErprisE ArchitEcturE

devices,whichtodayallowbrowsing,email,andvoice-over-IP capabilities. Such mobile devicesarebecomingmainstreamtargetsastheyacquiremorefunctionality.

Methods define the type of application theuser interactswithtoget information.Classicalcomputerapplicationsarelosinggroundinfavorof browser-based and messaging applications.Notonlywillemailmovetomobiledevices,butsowill subscription reports viaRSS feeds.An-othercategoryoflightapplications,suchasthosethat enable alerts with acknowledgment andworkflow approval capabilities, will become in-creasinglypopular.Generalportalswillno lon-gerbeadequatebecauseapplicationswillneedtopersonalizeandcustomizeportalcontenttorolesso that business users can inherit all that’s re-quired(reports,authority,andsoon)whiletheyoccupythatrole.

Tools let users find (and hopefully not justsearch),share,andcollaborateincreativewayswithnonetwork—butwithinsecurity—boundaries.

Concerns. The largestconcernhere is securityidentity management, which must encompassnot only federated authentication and authori-zationoutsideanorganization’sboundariesbut

alsopersonalization,learningortalentmanage-ment, role definition, and every aspect of hu-mans,be they employees, customers, suppliers,orcompetitors.

Having a single search interface for anythingand everything is a huge challenge. More so isfinding rather than searching. Finding impliesstructure,whichimpliestaxonomies,whichim-pliesmetadata—allvaporwareinmanyorganiza-tions.Social taggingmightbeananswer to themetadatadilemma,butit’snotastandardizedso-lution,andisn’treadyforannotationofstructureddataortobecentralizedinasinglerepository.

R ecent activity has focused extensively onthetoptwolayers:SLandIL.TheSLre-ceives thehighest attentiondue tomany

technology developments in mobility, unifiedcommunications,andWeb2.0applications,suchasportals,personalization,collaboration,andso-cialnetworking. In the IL,business intelligencebrings analytics from structured content alongwith relevantunstructured content topresent abusinessstoryorvalidateahypothesisbasedonasetofwell-managedbusinessrules.

I presented the technologies and concernssections of each layer to illustrate our points,butmoreanalysis,formalization,andclassifica-tionareneededsothatvarioustopicscanfitinwell-defined areas. This exercise should be asexhaustiveaspossible,formingasingleEAtax-onomy.Here,Ibasicallycallfororganizationstogoonestepclosertoenterpriseengineering,us-ingengineeringandscientificmethodstomodeltheenterprise.

References 1. M.A.Cook,Building Enterprise Information Architectures

Reengineering Information Systems,PrenticeHall,1996. 2. J.A. Zachman, “A Framework for Information Sys-

temsArchitecture,”IBM Systems J.,vol.26,no.3,1987.

Waleed Nema is an applications architect at Saudi Aramco. His research interests include the various archi-tecture disciplines, data services, and human information behavior. Nema is a PhD candidate at theInformatics Research Centre, University of Reading, UK. Prior to join-ing Saudi Aramco, he ran a US consulting firm in the areas of development, databases, and systems. Contact him at waleed.nema@gmail.com.

Learn about computing history and the people who shaped it.

COMPUTING THEN

http://computingnow.computer.org/ct