ENTERPRISE ARCHITECTURE AND SDLC PHASES 1

Enterprise Architecture and SDLC Phases

Name:

Institution:

Course:

Instructor:

Date:

Enterprise Architecture and SDLC Phases

Introduction

Enterprisearchitecture (EA) practitioners, who are commonlychristenedenterprisearchitects, analyzegivenbusinessorproductionprocesses as well as structures. Often, theyappraiseinformationgathered to further EA goals: durability, effectiveness, agility, andefficiency (Evernden, 1996; Rodgerb & Subramanian, 2008). There is no universally-accepted definition of what EA eventhoughdiverseorganizationspromoteownappreciation of theterm. Elementarily, EA is a coreelement of systemsdevelopmentaccording to Jarvis (2003) and Lapalme (2012).

EA contributes to thedevelopment of optimal designs of givensystems. Itfacilitateseffective allocation of resources during thesystems’ development as well as testingaccording to Evernden (1996) and Rodgerb and Subramanian (2008). Thatmeansthat EA is ratherhelpful in thewhole of an SLDC (Systems Development Life Cycle). Essentially, the SLDC of a givensystementails its planning, creation, testing as well as deployment. EA is critical in supplementing, as well as enabling, each of these SLDC phases as demonstrated by Pulkkinen, Naumenko and Luostarinen (2007).

Definition of Enterprise Architecture

EA is defineddifferently by differentorganizationsand EA practitioners. First, EA is characterized as a well-characterized practiceforexecutingenterprisedesign, appraisal, planning, as well as implementation, utilizing holistic strategiesalwaysaccording to Evernden (1996) and Rodgerb and Subramanian (2008).Second, at the Massachusetts Institute of Technology, EA is defined as logicfororganizingbusinessinfrastructureandprocessesmirroringthestandardizationandintegrationneeds of a business’ operatingmodelaccording to Pulkkinen, Naumenko and Luostarinen (2007).Essentially, themodel is thepreferredconditionforthestandardizationandintegration of thebusiness’ processes to deliverproducts to owncustomers optimally.

Third, EA is characterized as a distinctpractice that analyzessharedactivityareas within givenorganizationsorbusinesses. Theareas are especiallytheoneswhereresources like information are traded to directprospectivestates from integratedstrategic, commercial, and technological viewpoints. Fourth, EA is defined as a disciplinefor holistically, as well as proactively, guiding enterprises through givenchanges (Pulkkinen, Naumenko & Luostarinen, 2007). Usually, thechanges are occasioned by process unsettling forces. Whentheforcesare experienced, EA helps in making out andappraisingthehandling of the resulting changes to generatefavorable organizational outcomesandvisionsaccording to Jarvis (2003) and Lapalme (2012).

Enterprise Architecture and SDLC Phases

Asnotedearlier, EA is critical in supplementing, as well as enabling, SLDC phases. These are theinitiationphase, andrequirementsanalysisphase, among others (Pulkkinen, Naumenko & Luostarinen, 2007).

  1. Initiation/Planning/Concept Phase

Theconcept, planning, orinitiation,phase is as known as thepreliminaryanalysisphase. Itis aimed at executingpreliminaryappraisals, proposingdifferentsolutions, describingcosts along with benefits, andsubmittingpreliminaryrecommendations as regardsgivensystemproblems (Evernden, 1996; Rodgerb & Subramanian, 2008). During thephase, system developers considereveryextantpriority, which would be impacted upon andhowit should be addressed. Feasibilitystudies are done during thephase to establishthe viability of improvingorreplacingthesystems in question. Thestudies should coverthesystems’ operational, economic, technical, political, legal, andhumanfactoraspects (Pulkkinen, Naumenko & Luostarinen, 2007).

In thepreliminaryanalysisphase, EA providescriticalinputprior to thehappening of in-depth vendormanagement. EA helpsdeterminetheapplication assets,orresources,that ought to be purchased (Pulkkinen, Naumenko & Luostarinen, 2007). Notably, during thephase, there are varioussignificantprocesses that establishgivenprojects’ coursesandtheapplicationresources that ought to be bought. Suchprocessesrelate to howparticularsolutions would be incorporated into givenenvironmentsandhowthey ought to be architected according to Jarvis (2003) and Lapalme (2012). Aswell, theprocessesrelate to whethergivenorganizations should customize, purchaseorbuildparticularsolutions.

  1. Requirements Analysis Phase

Therequirementsdefinitionphaseentailsthe characterization of theprojectaims into distinctoperationsandfunctions of theanticipatedapplications. Elementarily, thephaseentailsthecollection along with interpretation of facts; diagnosis of extantproblems; andrecommendation of systemimprovements. In thephase, EA comes in handy in theanalysis of theinformationrequirements of intended end-users andremovingany incompleteness andinconsistencies in therequirementsaccording to Jarvis (2003) and Lapalme (2012). EA helpsappraisetheplannedsystemsandpreparingthenecessaryspecifications (Pulkkinen, Naumenko & Luostarinen, 2007).

  1. Design Phase

Thesystemsdesignstepentailsthedescription of thepreferredoperationsandfeatures comprehensively. Theoperationsandfeaturesinclude pseudocodes, screenlayouts, processdiagrams, andbusinessrules. Essentially, thephase is aimed at describingtheplannedsystemsas sets of subsystems or modules. In thedesignphase, characteristically, enterprisearchitects depend on developers along with domainarchitects to describetheplannedsystemsas sets of subsystems or modules to the micro-degree of detailaccording to Pulkkinen, Naumenko and Luostarinen (2007). EA practitioners visualizehowthe subsystems or modules will fit into given enterprises (Pulkkinen, Naumenko & Luostarinen, 2007). Theycreatehelpfuldesignpatternsand optimize designconfigurationeffortsaccording to Jarvis (2003) and Lapalme (2012). Theyhelpreviewsystemdesignsaltogetherfollowing their completion.

  1. Development Phase

During thedevelopmentstage, theactualcodes are written. In thestage, EA practitioners help in optimizing application coding efforts. Aswell, theyprovideinsights into thestandardization of the coding processes. Theyensurethattheprocessesfollowlaid down governance regulationsaccording to Pulkkinen, Naumenko and Luostarinen (2007).

  1. Integration and Testing Phase

In theintegration along with testingstage, allpieces of givencodes are gathered into suitabletestingenvironments, checkedforextanterrorsandbugs, andtestedfor interoperability. In thephase, user-acceptance, system, andunittests are commonlyperformed. Whenthetestingcycles are underway, EA practitioners determinehowtheattendantapplications may be changed to optimize their eventualutilityaccording to Jarvis (2003) and Lapalme (2012). Ifthepractitionersestablishthat there are considerablearchitecturalchanges, theyreviewthechangesandassistprojectteams in steering them appropriately.

  1. Implementation/Deployment/Support/Maintenance Step

In thisfinal SLDC phase, software is committed to productionprocessesandrunning of actualbusinesses. Particularly, software maintenanceentailstheassessment of systems to makesuretheydo not turn into obsolescence (Blanchard & Fabrycky, 2006; Marakas & O'Brien, 2010). In thisphase, EA guidesthemaking of therequisitechanges to theoriginal software to makesuretheydo not turn into obsolescence (Evernden, 1996; Rodgerb & Subramanian, 2008). System deployment includesenhancementsandchangesprior to givensystems’ sunsetor decommissioning. Whenthe operational stages of software deployment are underway, EA practitioners should not be engaged except when there are explicitneeds (Pulkkinen, Naumenko & Luostarinen, 2007). Eventhen, theyprovehelpful in optimize software deployment efforts.

References

Blanchard, B. & Fabrycky, J. (2006). Systems engineering and analysis. New Jersey: Prentice

Hall.

Evernden, R. (1996). The Information FrameWork. IBM Systems Journal, 35(1), 37-68.

Jarvis, B. (2003). Enterprise Architecture: Understanding the Bigger Picture – A Best

Practice Guide for Decision Makers in IT. Manchester: UK National Computing Centre.

Lapalme, J. (2012). Three Schools of Thought on Enterprise Architecture. IT Professional,

14(6), 37–43.

Marakas, J. & O’Brien, G. (2010). Management information systems. New York: McGraw-

Hill.

Pulkkinen, M., Naumenko, A. & Luostarinen, K. (2007). Managing information security in a

business network of machinery maintenance services business - Enterprise architecture as a coordination tool. J. Syst. Software, 80, 1607-1620.

Rodgerb, J. & Subramanian, G. (2008). Information and Software Technology. Science

Direct, 50(12), 1181-1188.