Convergent Architecture: Building Model Driven J2EE Systems with UML [1st ed.] 0471105600, 9780471105602

Citation preview

Convergent Architecture

Table of Contents

Conve r ge n t Ar chit e ct ur e —Bu ilding M ode l- D r ive n J2 EE Syst e m s w it h UM L Convergent Archit ect ure: Building Model Driven J2EE Syst em s wit h UML

by Richard Hubert John Wiley & Sons © 2002 Com panion Web Sit e

Print er friendly form at

Ta ble of Con t e nt s Convergent Ar chit ect ur e—Building Model- Driven J2EE Syst em s wit h UML For eword I nt r oduct ion I T- Archit ect ur al St yle—Professional engineering disciplines use archit ect ural st yles

Chapt er 2 -

The Conver gent Archit ect ur e Roadm ap—Defining and m anaging t he big pict ur e

Chapt er 3 -

The Conver gent Archit ect ur e Met am odel—The vision and principles of t he archit ect ure

Chapt er 4 -

The Conver gent Com ponent Met am odel—Com ponent s as t he vehicle of archit ect ure

AM FL Y

Chapt er 1 -

Chapt er 5 - The I T- Organizat ion Model—The business of building I T syst em s Chapt er 6 - The Developm ent Process Model

Chapt er 7 - The Archit ect ural I DE—Aut om at ing t he ar chit ect ur e Bibliography I ndex List of Figures List of Tables

TE

Chapt er 8 - Tut or ial Exam ple: Apply ing t he Convergent Ar chit ect ur e

-1-

Team-Fly®

Convergent Architecture

Press Information

Con ve r ge n t Ar ch it e ct u r e —Bu ildin g M ode l- D r ive n J2 EE Syst e m s w it h UM L Richa r d H ube r t

Wiley Com put er Publishing

John Wiley & Sons, I nc.

Publishe r : Robert I psen Edit or : Robert Elliot t Assist a n t Edit or : Em ilie Herm an M a na ging Edit or : John At kins Associa t e N e w M e dia Edit or : Brian Snapp Te x t D e sign & Com posit ion: MacAllist er Publishing Services, LLC Designat ions used by com panies t o dist inguish t heir product s are oft en claim ed as t radem arks. I n all inst ances where John Wiley & Sons, I nc., is aware of a claim , t he product nam es appear in init ial capit al or ALL CAPI TAL LETTERS. Readers, however, should cont act t he appropriat e com panies for m ore com plet e inform at ion regarding t radem arks and regist rat ion. Copyright © 2002 by Richard Hubert . All right s reserved. Published by John Wiley & Sons, I nc. Published sim ult aneously in Canada. No part of t his publicat ion m ay be reproduced, st ored in a ret rieval syst em or t ransm it t ed in any form or by any m eans, elect ronic, m echanical, phot ocopying, recording, scanning or ot herw ise, except as perm it t ed under Sect ions 107 or 108 of t he 1976 Unit ed St at es Copyright Act , wit hout eit her t he prior writ t en perm ission of t he Publisher, or aut horizat ion t hrough paym ent of t he appropriat e per- copy fee t o t he Copyright Clearance Cent er, 222 Rosewood Drive, Danvers, MA 01923, ( 978) 750- 8400, fax ( 978) 750- 4744. Request s t o t he Publisher for perm ission should be addressed t o t he Perm issions Depart m ent , John Wiley & Sons, I nc., 605 Third Avenue, New York, NY 10158- 0012, ( 212) 850- 6011, fax ( 212) 850- 6008, E- Mail: < PERMREQ@WI LEY.COM> . This publicat ion is designed t o provide accurat e and aut horit at ive inform at ion in regard t o t he subj ect m at t er covered. I t is sold wit h t he underst anding t hat t he publisher is not engaged in professional services. I f professional advice or ot her expert assist ance is required, t he services of a com pet ent professional person should be sought . Libr a r y of Congr e ss Ca t a loging- in- Publica t ion D a t a Hubert , Richard Convert ent archit ect ure: building m odel- driven J2EE syst em s wit h UML / Richard Hubert . p. cm .

-2-

Convergent Architecture

Press Information

" Wiley Com put er Publishing." I ncludes bibliographical references and index. I SBN: 0- 471- 10560- 0 1. Com put er archit ect ure.2. Syst em design.3. I nform at ion t echnology.I . Tit le. QA76.9.A73 A82 2001 658.4'038'011- - dc21 2001046537 10 9 8 7 6 5 4 3 2 1 Adva nce Pr a ise for Conve r ge nt Ar chit e ct ur e : Buildin g M ode l- D r ive n J2 EE Syst e m s w it h UM L " Soft w are engineering is a well est ablished discipline by now. However, t he role and im port ance of a proper underlying archit ect ure is very oft en not yet recognized by t he soft ware com m unit y. This book- wit h it s posit ioning of archit ect ural st yles in general and t he Convergent Archit ect ure specificallyprovides anot her m aj or st ep t owards t he ult im at e goal of archit ect ure- driven soft ware engineering. This is crit ical for com panies t hat wish t o m eet t he specific challenges of t oday's e- business world- flexibilit y and adapt abilit y, t im e- t o- m arket , and qualit y of soft ware solut ions. The aut hor not only describes t he fundam ent al principles of Convergent Archit ect ure and t he int egrat ion of syst em design wit h business and proj ect design, but also covers t he m et hodology, organizat ional st ruct ure, and support necessary t o effect ively t ranslat e t he concept ual fram ework int o act ion." Jürgen Henn Principal and Pract ice Leader, e- business Archit ect ure Consult ing I BM Business I nnovat ion Services " Bridges generally work reliably. Large soft ware syst em s generally don't . The essent ial difference is in design com plexit y, and in our inabilit y t o t am e it . I ronically t he m anagem ent of t his com plexit y has precedent s in t he archit ect ure of buildings, and in t his book Richard Hubert ident ifies t he concept of Archit ect ural St yles as t he m issing ingredient in large soft ware init iat ives. Archit ect ural St yles and t he Convergent Archit ect ure are about syst em at ic reuse and progressive refinem ent of collect ive soft ware design wisdom . Anyone involved in com plex soft ware proj ect s should read t his book cover t o cover." Barry Morris Chief Execut ive, Tot al Business I nt egrat ion " Engineers dream of a t ool- support ed design process for t ransform ing high- level m odels of syst em requirem ent s int o robust syst em s. I n soft w are engineering t here are m any part ial answers, but a com prehensive approach has been lacking unt il now. This book gives a lucid account of a full life- cycle approach t o designing large- scale, I nt ernet - orient ed business syst em s where Model Driven Archit ect ure, com bined wit h a m at ure archit ect ural st yle, is t he key. Readers- whet her m anagers, designers, or program m ers- will profit from t his and incorporat e archit ect urecent ric design in t heir ow n pract ice." Dr. David Basin Professor for Soft ware Engineering Universit y of Freiburg, Germ any To St ephanie

-3-

Convergent Architecture

Press Information

OM G Pr e ss Book s in Pr int ( For com plet e inform at ion about current and upcom ing t it les, go t o www .wiley.com / com pbooks/ om g/ ) Building Business Obj ect s by Pet er Eeles and Oliver Sim s, I SBN: 0471- 19176- 0. Business Com ponent Fact ory: A Com prehensive Overview of Com ponent - Based Developm ent for t he Ent erprise by Pet er Herzum and Oliver Sim s, I SBN: 0- 471- 32760- 3. Business Modeling wit h UML: Business Pat t erns at Work by HansErik Eriksson and Magnus Penker, I SBN: 0- 471- 29551- 5. CORBA 3 Fundam ent als and Program m ing, 2 nd Edit ion by Jon Siegel, I SBN: 0- 471- 29518- 3. CORBA Design Pat t erns by Thom as J. Mowbray and Raphael C. Malveau, I SBN: 0- 471- 15882- 8. Ent erprise Applicat ion I nt egrat ion wit h CORBA: Com ponent and Web- Based Solut ions by Ron Zahavi, I SBN: 0- 471- 32720- 4. Ent erprise Java wit h UML by CT Arringt on, I SBN: 0- 471- 38680- 4 Ent erprise Securit y wit h EJB and CORBA by Bret Hart m an, Donald J. Flinn and Konst ant in Beznosov, I SBN: 0- 471- 15076- 2. The Essent ial CORBA: Syst em s I nt egrat ion Using Dist ribut ed Obj ect s by Thom as J. Mowbray and Ron Zahavi, I SBN: 0- 47110611- 9. I nst ant CORBA by Robert Orfali, Dan Harkey and Jeri Edwards, I SBN: 0- 471- 18333- 4. I nt egrat ing CORBA and COM Applicat ions by Michael Rosen and David Curt is, I SBN: 0- 471- 19827- 7. Java Program m ing wit h CORBA, Third Edit ion by Gerald Brose, Andreas Vogel and Keit h Duddy, I SBN: 0- 471- 24765- 0. The Obj ect Technology Casebook: Lessons from Award- Winning Business Applicat ions by Paul Harm on and William Morrisey, I SBN: 0- 471- 14717- 6. The Obj ect Technology Revolut ion by Michael Gut t m an and Jason Mat t hews, I SBN: 0- 471- 60679- 0. Program m ing wit h Ent erprise JavaBeans, JTS and OTS: Building Dist ribut ed Transact ions wit h Java and C+ + by Andreas Vogel and Madhavan Rangarao, I SBN: 0- 471- 31972- 4. Program m ing wit h Java I DL by Geoffrey Lewis, St even Barber and Ellen Siegel, I SBN: 0- 471- 24797- 9. Quick CORBA 3 by Jon Siegel, I SBN: 0- 471- 38935- 8. UML Toolkit by Hans- Erik Eriksson and Magnus Penker, I SBN: 0471- 19161- 2. Abou t t he OM G The Obj ect Managem ent Group ( OMG) w as chart ered t o creat e and fost er a com ponent - based soft ware m arket place t hrough t he st andardizat ion and prom ot ion of obj ect - orient ed soft ware. To achieve t his goal, t he OMG specifies open st andards for every aspect of dist ribut ed obj ect com put ing from analysis and design, t hrough infrast ruct ure, t o applicat ion obj ect s and com ponent s. The well- est ablished Com m on Obj ect Request Broker Archit ect ure ( CORBA) st andardizes a plat form - and program m ing- language- independent dist ribut ed obj ect com put ing environm ent . I t is based on OMG/ I SO I nt erface Definit ion Language ( OMG I DL) and t he I nt ernet I nt er- ORB Prot ocol ( I I OP) . Now recognized

-4-

Convergent Architecture

Press Information

as a m at ure t echnology, CORBA is represent ed on t he m arket place by well over 70 Obj ect Request Brokers ( ORBs) plus hundreds of ot her product s. Alt hough m ost of t hese ORBs are t uned for general use, ot hers are specialized for real- t im e or em bedded applicat ions, or built int o t ransact ion processing syst em s w here t hey provide scalabilit y, high t hroughput , and reliabilit y. Of t he t housands of live, m ission- crit ical CORBA applicat ions in use t oday around t he world, over 300 are docum ent ed on t he OMG's success- st ory Web pages at ww w.corba.org. CORBA 3, t he OMG's lat est release, adds a Com ponent Model, qualit y- of- service cont rol, a m essaging invocat ion m odel, and t ight ened int egrat ion wit h t he I nt ernet , Ent erprise Java Beans, and t he Java program m ing language. Widely ant icipat ed by t he indust ry, CORBA 3 keeps t his est ablished archit ect ure in t he forefront of dist ribut ed com put ing, as will a new OMG specificat ion int egrat ing CORBA wit h XML. Wellknown for it s abilit y t o int egrat e legacy syst em s int o your net work, along wit h t he w ide variet y of het erogeneous hardware and soft ware on t he m arket t oday, CORBA ent ers t he new m illennium prepared t o int egrat e t he t echnologies on t he horizon. Augm ent ing t his core infrast ruct ure are t he CORBA services, which st andardize nam ing and direct ory services, event handling, t ransact ion processing, securit y, and ot her funct ions. Building on t his firm foundat ion, OMG Dom ain Facilit ies st andardize com m on obj ect s t hroughout t he supply and service chains in indust ries such as Telecom m unicat ions, Healt hcare, Manufact uring, Transport at ion, Finance/ I nsurance, Elect ronic Com m erce, Life Science, and Ut ilit ies. The OMG st andards ext end beyond program m ing. OMG Specificat ions for analysis and design include t he Unified Modeling Language ( UML) , t he reposit ory st andard Met a- Obj ect Facilit y ( MOF) , and XML- based Met adat a I nt erchange ( XMI ) . The UML is a result of fusing t he concept s of t he world's m ost prom inent m et hodologist s. Adopt ed as an OMG specificat ion in 1997, it represent s a collect ion of best engineering pract ices t hat have proven successful in t he m odeling of large and com plex syst em s and is a well- defined, w idely accept ed response t o t hese business needs. The MOF is OMG's st andard for m et am odeling and m et a dat a reposit ories. Fully int egrat ed wit h UML, it uses t he UML not at ion t o describe reposit ory m et am odels. Ext ending t his work, t he XMI st andard enables t he exchange of obj ect s defined using UML and t he MOF. XMI can generat e XML Dat a Type Definit ions for any service specificat ion t hat includes a norm at ive, MOF- based m et am odel. I n sum m ary, t he OMG provides t he com put ing indust ry w it h an open, vendorneut ral, proven process for est ablishing and prom ot ing st andards. OMG m akes all of it s specificat ions available wit hout charge from it s Web sit e, www.om g.org. Wit h over a decade of st andard- m aking and consensus- building experience, OMG now count s about 800 com panies as m em bers. Delegat es from t hese com panies convene at week- long m eet ings held five t im es each year at varying sit es around t he world, t o advance OMG t echnologies. The OMG welcom es guest s t o t heir m eet ings; for an invit at ion, send your em ail request t o < info@om g.org> . Mem bership in t he OMG is open t o end users, governm ent organizat ions, academ ia, and t echnology vendors. For m ore inform at ion on t he OMG, cont act OMG headquart ers by phone at 1- 508- 820- 4300, by fax at 1- 508- 820- 4303, by em ail at < info@om g.org> , or on t he Web at www .om g.org. 2 0 0 1 OM G Pr e ss Advisor y Boa r d

-5-

Convergent Architecture

Press Information

Ka r e n D . Bouche r Execut ive Vice President The St andish Group Ca r ol C. Bur t President and Chief Execut ive Officer 2AB, I nc. Sr idha r I ye nga r Unisys Fellow Unisys Corporat ion Cr is Kobr yn Chief Technologist Telelogic N ilo M it r a , Ph.D . Principal Syst em Engineer Ericsson Jon Sie ge l, Ph.D . Direct or, Technology Transfer Obj ect Managem ent Group, I nc. Richa r d M a r k Sole y, Ph.D . Chairm an and Chief Execut ive Officer Obj ect Managem ent Group, I nc. She ldon C. Sut t on Principal I nform at ion Syst em s Engineer The MI TRE Corporat ion Ack now le dgm e nt s I would like t o t hank and at t he sam e t im e congrat ulat e t he m any convergent engineers and inform at ion t echnology ( I T) consult ant s who have helped evolve, t est , and refine t he concept s of t he Convergent Archit ect ure t hroughout num erous proj ect s. This includes, of course, t he consult ant s and developers at I nt eract ive Obj ect s Soft w are Gm bH, who cont inue t o serve as sparring part ners and codevelopers of t he Convergent Archit ect ure. The cont ent s of t his book bear clear wit ness t o t he value of our long- t erm t eam effort . Alt hough t his book builds on t he accom plished works of m any expert s, part icular recognit ion goes t o m y friend and m ent or, Dr. David A. Taylor, who not only helped t he I T indust ry explain obj ect t echnology t o t he m asses but also back in 1995, wit h his book on convergent engineering, helped us discern t he crit ical pat h of I T archit ect ure t hrough t he next decades of t he I nt ernet age. Wit hout David's cont ribut ion, t he " Convergent " in Convergent Archit ect ure would not exist . Last but not least , I would like t o t hank m y reviewers, in part icular Dr. Jan Vest er from Sim ulacrum Gm bH and Axel Uhl from iO Gm bH, whose relent less const ruct ive feedback and at t ent ion t o det ail helped im prove t his book in m any aspect s. RI CH ARD H UBERT is an accom plished soft ware archit ect who has own num erous int ernat ional aw ards for large- scale soft ware syst em s and archit ect ural t ools. As founding direct or of I nt eract ive Obj ect s Soft ware Gm bH ( iO) , he leads a large t eam of professional archit ect s who apply Convergent Archit ect ure across diverse indust ry segm ent s. I n 2000, iO int roduced it s Archit ect ural I DE for MDA, ArcSt yler. The aut hor is also an act ive cont ribut or t o t he OMG's MDA st andardizat ion effort .

-6-

Convergent Architecture

Foreword

For e w or d I m agine if every office building was designed and engineered from scrat ch. I m ean t ruly from scrat ch, wit h each archit ect working from first principles t o solve t he problem s of fabricat ing raw m at erials, achieving st ruct ural int egrit y, providing prot ect ion from t he elem ent s, put t ing out fires, m oving people am ong t he floors, and delivering air, light , power, and w at er t o t he occupant s. I t would be a disast er. The cost s w ould be ast ronom ical; each building would be an isolat ed t ower of oneoff syst em s, and m aint enance would be an engineering night m are. Worse, cat ast rophic failures would be so rout ine t hat t hey wouldn't even m ake t he m orning paper. Does t his sound fam iliar? I t should; it 's a fair port rayal of how business soft w are is designed and const ruct ed t oday. The result s are no bet t er t han we have a right t o expect . Som eday, applicat ion developm ent will out grow it s painful adolescence and gain t he kind of m at urit y t hat building archit ect ure now enj oys. As wit h m odern office buildings, business applicat ions will be assem bled out of proven com ponent s t hat offer st andard solut ions t o recurring problem s. Each will be a unique const ruct ion, but —like buildings—t hey will share com pat ible subsyst em s, be easily m aint ained, and deliver reliable service. This book is a sem inal cont ribut ion t o t hat goal. I t offers, bot h t hrough it s cont ent and by t he exam ple it set s, t he possibilit y of coherent archit ect ures for business soft ware. The part icular archit ect ure it describes, t he Convergent Archit ect ure, m ay well be t he m ost com prehensive, det ailed fram ework ever proposed for largescale business applicat ions. Alt hough m any part s of t he archit ect ure are new, it incorporat es t he best of current pract ices, such as Model Driven Archit ect ure ( MDA) , Responsibilit y Driven Design ( RDD) , and t he Unified Modeling Language ( UML) . The inspirat ion for t his archit ect ure is a discipline called convergent engineering—a discipline m y colleagues and I developed a decade ago t o facilit at e t he design of scalable, m aint ainable business syst em s. The founding prem ise of convergent engineering is t hat t he design of a business and it s support ing soft ware should be one and t he sam e. For each key elem ent of t he business, t here is a corresponding soft ware obj ect t hat act s on it s behalf. These obj ect s com e in m any form s, but t hey fall int o t hree broad cat egories: organizat ions, processes, and resources. Rules govern how t hese t hree kinds of obj ect s can be com bined and how t hey int eract . For exam ple, processes consum e and generat e resources, and can t ake place only in t he cont ext of an owning organizat ion. These rules bring useful order t o t he difficult t ask of re- engineering a business, and t hey do so in a way t hat direct ly specifies t he soft w are t o support t hat business. Richard Hubert learned convergent engineering in May 1996, when he t ook m y week- long cert ificat ion course at t he Convergent Engineering I nst it ut e ( CEI ) . Wit hin a year, Richard had gone on t o receive his m ast er's cert ificat e, ent it ling him t o cert ify ot hers, and had opened t he second int ernat ional branch of CEI in Freiburg, Germ any. He and his st aff of consult ant s at I nt eract ive Obj ect s Soft ware ( iO) were soon using convergent engineering in large- scale developm ent proj ect s t hroughout Germ any, com bining it w it h ot her t echniques t o expand it int o a m ore com prehensive archit ect ural st yle.

-7-

Convergent Architecture

Foreword

Frust rat ed by t he lack of adequat e t ools, Richard and his t eam began developing soft ware t o bet t er capt ure t he result s of t heir design effort s and t o aut om at e t he generat ion of code. The end result was t he release of iO's award- winning ArcSt yler product , a suit e of t ools t hat m odels a business in t erm s of organizat ions, processes, and resources, and t hen drives t hat m odel int o an execut able syst em t hat can be deployed on any of t he m aj or Java applicat ion servers. Rem arkably, t he business m odel rem ains visible t hroughout t he developm ent lifecycle. I f a process is im proved or an organizat ion rest ruct ured, t he necessary changes are m ade t o t he corresponding business obj ect s using high- level design t ools, not by alt ering t he low- level code. The t ool is a com pelling dem onst rat ion of Convergent Archit ect ure, and it gives t he archit ect ure a solid grounding in t he hard realit ies of soft ware developm ent . The archit ect ure described in t his book is a significant cont ribut ion t o t he soft ware indust ry on t wo dist inct levels. At t he m ost evident level, it provides a det ailed prescript ion for applicat ion developm ent , one t hat can be adopt ed as is or adapt ed as desired. At a deeper level, it illust rat es t he kind of effort t hat w ill be necessary t o im pel t he indust ry out of it s prolonged adolescence and int o a m at ure engineering discipline. For t he first t im e, we have a coherent , com pelling vision for applicat ion archit ect ure com bined wit h precise inst ruct ions for im plem ent ing t hat vision, including all t he necessary t ools t o go from concept t o code. I t is a com binat ion t hat is cert ain t o raise t he bar for t he applicat ion- developm ent com m unit y. —D a vid Ta ylor , Aut hor , Business Engineering wit h Obj ect Technology

-8-

Convergent Architecture

Introduction

I n t r odu ct ion But w ha t ' s t he point of h a ving e ve r yt hin g m e a sur e d by pole s? W hy not build e ve r yt hing higge dy pigge dy, lik e a house ? Fir st , be ca use it 's che a pe r t his w a y. All t he a r che s of t he a r ca de a r e ide nt ica l, so w e ca n r e - use t he fa lse w or k a r che s. The fe w e r diffe r e nt size s a nd sha pe s of st one w e ne e d, t he fe w e r t e m pla t e s I h a ve t o m a k e . And so on. Se con d, it sim plifie s e ve r y a spe ct of w ha t w e ' r e doing, fr om t h e or igina l la ying- out — e ve r yt hing is ba se d on a pole squa r e - t o pa int ing t he w a lls — it ' s e a sie r t o e st im a t e how m uch w hit e w a sh w e ' ll ne e d. And w he n t hin gs a r e sim ple , fe w e r m ist a k e s a r e m a de . Th e m ost e x pe nsive pa r t of building is t he m ist a k e s. Thir d, w he n e ve r yt hing is ba se d on a pole m e a sur e , t he chur ch j ust look s r ight . Pr opor t ion is t he h e a r t of be a ut y. Ke n Folle t t , The Pilla r s of t he Ea r t h Would any serious engineer design a j et airplane wit h a helicopt er propeller on t op of it ? Com m on sense would t ell any decision m aker t hat such an aircraft would hardly be able t o t ake off. And t he approaches and m et hods used in m at ure engineering disciplines, such as aeronaut ics, sim ply prohibit such a developm ent .

Yet , irrespect ive of your posit ion in t he inform at ion t echnology ( I T) indust ry, you will alm ost definit ely have com e across a soft ware syst em or an I T organizat ion t hat very m uch looks like a j et airplane wit h a helicopt er propeller on t op of it . Even t hough as m em bers of t he I T indust ry w e are aware of t he problem s of poor design, inefficient organizat ions, and ad- hoc solut ions, m ost of us have been asked t o buy, design, or part icipat e in t he developm ent of such a t hing. What is it t hat dist inguishes m at ure engineering disciplines from our indust ry? The answer is archit ect ural st yle—t he m ain t opic of t his book. Have you ever wondered why syst em developm ent is st ill so com plex despit e t he rich array of product s, t echniques, and t ools available t oday? Cert ainly, m odern developm ent aids such as design m et hodologies, pat t erns, com put er- aided syst em s engineering ( CASE) t ools, Web applicat ion servers, and packaged solut ions—j ust t o nam e a few exam ples—can serve as useful part s of an I T st rat egy. However, j ust having t hese diverse part s is not enough. To be effect ive, all t hese pieces m ust be posit ioned wit hin t he cont ext of an I T archit ect ure. Few would disput e t his st at em ent , but repeat edly achieving good I T archit ect ure in diverse sit uat ions has long been an elusive t ask. This is m ost ly because t rying t o nail down t he key aspect s of I T archit ect ure leads t o som e ot her fundam ent al quest ions: ƒ ƒ

-9-

What role does I T archit ect ure play in our overall I T st rat egy, and w hat does t his look like? How can we repeat edly achieve t he advant ages of solid I T archit ect ure across m ult iple t eam s and even across globally dist ribut ed organizat ions?

Convergent Architecture

ƒ ƒ

Introduction

How can our exist ing I T organizat ion evolve t o new levels of archit ect ural qualit y in realist ic increm ent s? Can we define and im plem ent an archit ect ural big pict ure t hat realist ically sim plifies all our diverse I T const ellat ions from a single proj ect t o a global I T landscape?

These are som e of t he quest ions answered by t his book, which defines I T archit ect ural st yle and dem onst rat es it s advant ages using a m at ure archit ect ural st yle called t he Convergent Archit ect ure. The qualit ies of good I T archit ect ure have always been difficult t o define and even m ore difficult t o reproduce consist ent ly in pract ice. I n fact , m any of t he qualit ies of good I T archit ect ure have been so elusive as t o rem ain undefined and unnam ed on t he whole. This book is about capt uring t hese qualit ies and m aking t hem syst em at ically at t ainable in pract ice. First and forem ost , t his book explains and applies I T archit ect ural st yle. I t defines I T archit ect ural st yle and gives a vague and am orphous set of key archit ect ural qualit ies bot h a nam e and a num ber of t angible feat ures. Then t he m aj or port ion of t he book proceeds t o show how t hese feat ures are applied in t he Convergent Archit ect ure. The Convergent Archit ect ure not only clearly dem onst rat es how archit ect ural qualit ies are capt ured in I T archit ect ural st yle, but also proves t hat t hey can be consist ent ly applied, t aught , and effect ively aut om at ed using available t echnologies. I t explains how t he Convergent Archit ect ure resolves m any of t oday's com plex I T- relat ed problem s at t he source inst ead of j ust dealing wit h t heir sym pt om s. By addressing t he sources of error and com plexit y, it revolut ionizes t he effect iveness of I T t eam s and, m ore significant ly, of whole I T organizat ions—w it h t he ret urns increasing in proport ion t o t he size of t he organizat ion. I n short , t his book dem onst rat es how t o achieve a new level of qualit y in I T syst em s. And t his qualit y now has a nam e: Convergent Archit ect ure. Second, t his book can be seen as t he applied sequel t o Dr. David A. Taylor's book ent it led, Convergent Engineering: Business Engineering wit h Obj ect Technology ( Wiley 1995) . The Convergent Archit ect ure was born out of applying t he concept s of Convergent Engineering in diverse corporat e environm ent s. One of it s principal goals is t o t ransport t he vision of Convergent Engineering int o t he field of applied archit ect ure. I n doing t his, it shows, for exam ple, how t o apply t he Rat ional Unified Process and t he concept s of t he OMG Model Driven Archit ect ure ( MDA) t o achieve Convergent Engineering using st at e- of- t he- art t ools and t echnology. Third, t his book is for pract it ioners. I t is writ t en not only for I T st rat egist s and chief archit ect s, but also for proj ect m anagers and developers in t he field. Alt hough beginning wit h t he im port ant concept ual underpinnings of I T archit ect ural st yle, it quickly m oves int o t he nut s- and- bolt s usage of Convergent Archit ect ure. The concept s, t echniques, and t ools em ployed in t his book have been t ried and t est ed in pract ice. They are t he result of hands- on experience in diverse environm ent s. Based on t his experience, t he Convergent Archit ect ure has defined how t o opt im ize t he applicat ion of t he Unified Modeling Language ( UML) , t he Rat ional Unified Process ( RUP) , and J2EE/ EJB t o achieve new levels of archit ect ural int egrit y. I t dem onst rat es how all t hese part s work t oget her in an int egrat ed t ool environm ent , t he archit ect ural I DE. I n t his sense, t he Convergent Archit ect ure is an archit ect ural st yle for MDA as current ly envisioned by t he OMG. As long- t im e m em bers of t he OMG, we are act ively part icipat ing in t he MDA init iat ive in order t o ensure

-10-

Convergent Architecture

Introduction

alignm ent of t he Convergent Archit ect ure and t o help drive progress in t his very prom ising area of st andardizat ion. Last ly, t his book present s an I T archit ect ural st yle t o t he public. I t put s a st ake in t he ground by defining som et hing concret e t hat can be used, discussed, and im proved on by m any part ies over t im e. We are convinced t hat t he Convergent Archit ect ure const it ut es a reasonable and logical st ep in t he ongoing evolut ion of t he I nform at ion Age. I n ot her words, we do not t hink t hat it is a quest ion of whet her m any of t he concept s dem onst rat ed in t his book becom e widely used in t he soft ware indust ry; rat her, it is j ust a quest ion of when and under what nam e or designat ion. We also believe t hat aft er reading t he first few chapt ers of t his book, st rat egic decision m akers will feel at hom e wit h our approach t o cont inuous long- t erm im provem ent . One of t he prim ary goals of t he Convergent Archit ect ure is t o help st rat egic I T m anagers at t he corporat e level t o inst ill a sense of overall direct ion and purpose int o t heir I T st rat egy. I t should help t hem rem ove num erous sources of com plexit y and st ress across t heir ent ire organizat ion and help t hem put an end t o t he frust rat ing cycles of react ive sym pt om cont rol. By int roducing t he era of corporat e archit ect ural st yle, t he Convergent Archit ect ure will help I T m anagers open new doors t o ot herwise unachievable ret urns at all levels of a business.

AM FL Y

H ow Th is Book I s Or ga n ize d

TE

This book proceeds wit h increasing levels of det ail. I t begins wit h t he design and j ust ificat ion of I T archit ect ural st yle in general and m oves on t o explain each part of t he Convergent Archit ect ure in a logical m anner. The coverage of t he Convergent Archit ect ure begins w it h an out line, or roadm ap, and t hen drills down int o t he specific feat ures of t he roadm ap. Each subsequent chapt er t hen describes t he design and j ust ificat ion of one of t hese feat ures. I t also explains how t o apply t his feat ure beginning at t he level of individual proj ect s on up t o t he level of corporat e I T organizat ion.

Chapt er 1 int roduces t he concept of archit ect ural st yle in general and it s pot ent ial in t he I T field. Analogies and exam ples are used from ot her indust ries t o explain t he significant advant ages at t ainable t hrough an I T archit ect ural st yle. I t also defines I T archit ect ural st yle and it s design—it s st ruct ure, m odels, principles, and relat ionships—and t he applicat ion of a st yle in realit y- scale sit uat ions. Chapt er 2 provides an overview and roadm ap of t he Convergent Archit ect ure as an I T archit ect ural st yle. I t describes how t he concept s and design from Chapt er 1 are applied in t he Convergent Archit ect ure. I t also present s t he anat om y and t he big pict ure of t he Convergent Archit ect ure, int roducing each st ylist ic feat ure and it s advant ages in real- world proj ect s. Each feat ure is t hen det ailed in t he rem aining chapt ers of t he book. Chapt er 3 j ust ifies and defines t he Convergent Archit ect ure m et am odel. This t oplevel feat ure of t he Convergent Archit ect ure com poses t he long- t erm vision and fundam ent al design principles of t he archit ect ural st yle. Chapt er 4 present s t he Convergent Com ponent m et am odel as a prim e vehicle of t he archit ect ure. This is t he first of t hree design m odels t hat visibly t ransport t he

-11-

Team-Fly®

Convergent Architecture

Introduction

principles from Chapt er 3 int o real- w orld m odeling st yles, t echniques, t ools, and aut om at ed infrast ruct ure m appings. I t defines t he applicat ion of MDA and an archit ect ural t ool suit e ( t he archit ect ural I DE) in t he cont ext of an archit ect ural st yle. Chapt er 5 out lines t he I T organizat ion m odel and it s applicat ion of t he RUP. This m odel const it ut es a concret e reference fram e for t he business of building I T syst em s in t he cont ext of an archit ect ural st yle. I t defines t he organizat ion, workers, roles, t ools, and int eract ions of all st akeholders in t he Convergent Archit ect ure. Chapt er 6 present s t he Developm ent - Process m odel, which com plem ent s t he I T organizat ion m odel. This det ailed developm ent process const it ut es an applied inst ance of t he RUP and it s archit ect ural t ool support in t he cont ext of t he archit ect ural st yle. Chapt er 7 illust rat es t he int egrat ed archit ect ural t ool suit e and how it support s t he archit ect ural st yle as defined in Chapt ers 1 t hrough 6—how it support s t he com ponent , organizat ion, and process m odels of t he Convergent Archit ect ure. The t ool suit e, known as an archit ect ural I DE, is described in det ail. The chapt er exhibit s how t he concept s of MDA and t he Convergent Archit ect ure are applied using an available archit ect ural I DE ( ArcSt yler) t hat em beds and drives best - ofbreed com ponent t ools such as Rat ional Rose, JBuilder, and diverse J2EE/ EJB applicat ion servers in t he cont ext of t he archit ect ural st yle. Chapt er 8 is a t ut orial t hat applies t he concept s of t he Convergent Archit ect ure in an end- t o- end exam ple using t he archit ect ural I DE. I t exhibit s each st ep of t he m odel- driven developm ent process from t he init ial business design t hrough t o t he generat ion, deploym ent , and t est ing of J2EE/ EJB com ponent s, including t heir Web services and Web front - ends. I t shows how MDA is support ed by t he archit ect ural I DE t o develop and m anage all four t iers of t he J2EE blueprint s ( J2EE Blueprint s 2001) in t he cont ext of a com prehensive archit ect ural st yle. I n addit ion, a bonus chapt er in Microsoft Word form at can be found on our com panion Web sit e ( www.Convergent Archit ect ure.com ) , which const it ut es a reference m anual and user's guide cont aining t he design and usage det ails of t he MDA m odeling st yles and t he J2EE/ EJB t echnology m appings t hat were int roduced in Chapt er 4 and applied t hroughout t he book. I t also shows how t hese feat ures are explicit ly support ed by t he archit ect ural I DE. This det ailed reference m at erial is available on t he Web so t hat it m ay be easily m aint ained, t hus providing t he reader wit h an up- t o- dat e version at all t im es. However, t he m at erial in t his chapt er can only be properly underst ood and applied when read in conj unct ion wit h t his book because t he chapt er m akes ext ensive reference t o t he archit ect ural concept s, t erm s, processes and t ools covered in Chapt ers 1 t hrough 8.

W h o Sh ou ld Re a d Th is Book A variet y of readers will be int erest ed in t he subj ect m at t er covered in t his book, each from a different perspect ive. The following reading sequence is recom m ended for each respect ive audience:

-12-

Convergent Architecture

ƒ

ƒ ƒ

Introduction

CEOs/ CI Os and business consult ant s will find t he m essage regarding I T- archit ect ural st yle and Convergent Archit ect ure in Chapt ers 1 t hrough 3 of part icular relevance. For t he next level of det ail, t hey should proceed t o t he int roduct ions in Chapt er 5, " The I T Organizat ion Model," and Chapt er 6, " The Developm ent - Process Model." Chief archit ect s, I T consult ant s, proj ect m anagers, lead developers, and t hose int erest ed in t he OMG Model- Driven Archit ect ure I nit iat ive are t he prim e audience for t he ent ire book. J2EE/ EJB developers and Web service developers m ay want t o first read t he t ut orial exam ple ( Chapt er 8) t o get a hands- on feeling for t he developm ent process and environm ent , and t hen m ove t o t he chapt ers explaining t he developm ent process ( Chapt er 6) , t he archit ect ural I DE ( Chapt er 7) , and t he det ails on t he Modeling St yle and Technology Proj ect ions ( t he bonus Web sit e chapt er) . At som e point , Chapt er 2 should be read in order t o bet t er underst and t he big pict ure and roadm ap of t he archit ect ural st yle.

Tools You W ill N e e d The exam ples in t he first seven chapt ers of t his book, as well as t he hands- on t ut orial in Chapt er 8, use t he following t ools t o dem onst rat e t he m odel- driven approach and t he int egrat ed archit ect ural environm ent : ƒ ƒ ƒ ƒ

A J2 EE/ EJB a pplica t ion se r ve r . Borland Applicat ion Server, BAS 4.5 or higher, available from www.Borland.com , or t he WebLogic Server 6.1 or higher, available from www.BEA.com . Ja va I D E. JBuilder or JBuilder Ent erprise version 5 or higher, which includes t he BAS applicat ion server, available from www.Borland.com . UM L M ode ling Tool. Rose 2001 or 2001 A Modeler Edit ion or higher, available from www .Rat ional.com . Ar chit e ct ur a l I D E. The lat est release of t he ArcSt yler Archit ect ural I DE for MDA, available from www.ArcSt yler.com .

Th e Con ve r ge n t Ar ch it e ct u r e W e b Sit e Of course, it is im possible t o put everyt hing concerning t he Convergent Archit ect ure int o a concise book out lining t he ent ire archit ect ural st yle. Ext ensive m at erial pert aining t o t he Convergent Architect ure is available in addit ion t o t his book. Also, t he Convergent Archit ect ure cont inues t o evolve, so new m at erial and updat es will em erge. Thus, a Web sit e has been creat ed t o accom pany t his book wit h new and com plem ent ary m at erial in a readily accessible forum at www .Convergent Archit ect ure.com . The basic cont ent s of t he sit e are as follows: ƒ

-13-

Tut orial and sam ple m at erial applying t he Convergent Archit ect ure including it s MDA/ RUP feat ures and t ools

Convergent Architecture

ƒ

ƒ

ƒ ƒ

ƒ

Introduction

References, case st udies, present at ions, papers, and dem onst rat ions Ext ended specificat ions and user guidelines Reusable asset s ranging from open- source, reusable proj ect ware t o ext ension m odules for t he archit ect ural I DE Updat es t o t he archit ect ural I DE and relat ed product inform at ion Cont act s, com m unit y, and event inform at ion

Fr om H e r e The concept s, t echniques, and t ools present ed in t his book have been applied in num erous I T environm ent s, bot h large and sm all, t o achieve significant ly higher levels of I T effect iveness. The purpose is t o enable corporat e archit ect s, CI Os, proj ect m anagers, and individual proj ect t eam m em bers t o im m ediat ely leverage MDA in t he cont ext of a holist ic archit ect ural approach by applying a well- defined I T archit ect ural st yle. We hope t hat t he definit ions and exam ples in t he init ial chapt ers convince you of t he far- reaching advant ages of I T archit ect ural st yle as we define it . Above all, we hope t o convey t he advant ages of a t ried and t est ed I T archit ect ural st yle, t he Convergent Archit ect ure, as a last ing rem edy t o significant problem s experienced by alm ost every I T organizat ion t oday. The bot t om line is t hat t he Convergent Archit ect ure was developed by pract icing I T archit ect s t o help any I T endeavor achieve higher goals. I t is about m aking t he sum of our effort s m uch great er t han t he individual part s. I t is about defining how we approach business design, proj ect design, and syst em design at all levels of an organizat ion in a cum ulat ively synergist ic m anner. I t is about put t ing diverse pieces t oget her in a holist ic big pict ure t o provide I T organizat ions wit h a longt erm vision and last ing im provem ent s. I t is about achieving a consist ent cycle of sim plificat ion and opt im izat ion across t he ent ire landscape of I T developm ent and t hroughout it s long- t erm evolut ion. And it 's about t he posit ive energies t hat we all share when we do t hings w it h st yle.

-14-

Convergent Architecture

Chapter 1: IT-Architectural Styel

Ch a pt e r 1 : I T- Ar ch it e ct u r a l St yle — Pr ofe ssion a l e n gin e e r in g disciplin e s u se a r ch it e ct ur a l st yle s Ove r vie w I n m any indust ries, engineers repeat edly im prove on large, com plex syst em s and achieve im pressive levels of product ivit y and qualit y. What enables indust rial archit ect s and airplane and aut om obile engineers t o deliver solid im provem ent s year aft er year? Why is t he soft ware indust ry st ill a far cry away from such engineering m at urit y? A key answer t o bot h t hese quest ions is archit ect ural st yle. This chapt er int roduces archit ect ural st yle as a crucial elem ent of m at ure engineering disciplines and suggest s how it m ay be applied t o obt ain t he sam e levels of m at urit y in t he inform at ion t echnology ( I T) indust ry. First , t his chapt er looks at how archit ect ural st yle has been used for cent uries t o ensure t he success of m aj or engineering effort s. Hist ory reveals archit ect ural st yle as t he m ost im port ant m eans of efficient , high- level com m unicat ion am ong developers. Wit hout it , we would not have m any of t he m ast erworks of archit ect ure and engineering t hat we now t ake for grant ed. Aft er t he short hist orical out line, I define m odern I T- archit ect ural st yle and explain how it m ay be applied t o im prove soft ware developm ent significant ly across t he board.

This chapt er focuses on t he definit ion of archit ect ural st yle, it s elem ent s, and it s principles in t he cont ext of soft ware engineering. These concept s form t he design foundat ion for t he Convergent Archit ect ure, an I T- archit ect ural st yle. You should read t his chapt er if you w ant t o underst and t he concept s of I T- archit ect ural st yle above and beyond t heir specific applicat ion in t he Convergent Archit ect ure. Above all, t his chapt er is im port ant if you want t o creat e your own I T- archit ect ural st yle or cont ribut e t o t he furt her developm ent of t he Convergent Archit ect ure.

D iscove r in g t h e Sou r ce of H igh Re t ur n s I n t he m id- and lat e 1990s, I was involved as chief archit ect in several large proj ect s. The requirem ent s in t hese proj ect s were all quit e sim ilar and are com m on t o alm ost every large inst it ut ion: An est ablished I T organizat ion wit h a com plex, het erogeneous landscape of m ission- crit ical syst em s needed t o m odernize and I nt ernet - enable it s corporat e I T infrast ruct ure. My m ission in each case was t o est ablish archit ect ure- driven design in t he exist ing I T organizat ion and t o ret urn t he int ernal I T t eam t o t he point of self- sufficiency using m odern archit ect ure, t ools, and t echnologies. I did not want t o leave t he t eam wit h a short - t erm solut ion; t o t he cont rary, t he biggest problem w as t he exist ing ad hoc landscape of short - t erm solut ions. I n each proj ect I w as cont inually confront ed wit h one cent ral problem : How t o effect ively inst ill archit ect ural concept s int o t he ent ire organizat ion? How t o get everybody working const ruct ively and in concert t ow ard t he com m on goal? How t o m ake t his a perm anent process of opt im izat ion, in every discussion, at every level, wit hout requiring an experienced archit ect t o be om nipresent in each inst ance? I n ot her words, how t o est ablish I T archit ect ure as

-15-

Convergent Architecture

Chapter 1: IT-Architectural Styel

a cult ure, a school of t hought across t he ent ire organizat ion, and not j ust as anot her short - t erm solut ion? These are not easy quest ions t o answ er as any lead developer or proj ect m anager can confirm , alt hough t hey are by no m eans unusual. Consult ant s are paid t o deal wit h j ust t hese t ypes of problem s. However, t here was som et hing else bot hering m e. I had a feeling t hat we—t he I T field at large—w ere st ill m issing out on som e approach, som e t echnique, som et hing, what ever it was, t hat ot her indust ries use in such sit uat ions. I t j ust appeared t o m e t hat ot her indust ries have reached a level of archit ect ural com pet ence and expression t hat we had not yet reached. I could not put m y finger on it , but t he feeling grew wit h each day. Maybe t his nagging feeling cam e from m y background first as a chem ical engineer and t hen as an I T archit ect . I n any case, I w ant ed t o figure it out and t o see if I could apply it t o solve m y problem .

My search int ensified. I w as reading everyt hing about proj ect m anagem ent , process m et hodologies, and I T design t hat I could get m y hands on. As early as 1994, t his search t ook m e t o Aust in, Texas, t o hear Jim Coplein ( 1995) , a fat her of t he pat t ern m ovem ent , speak about I T design pat t erns. I ndeed, pat t erns were helpful, as t hey st ill are, but neit her pat t erns nor any ot her available I T knowledge allayed m y suspicion t hat we were st ill m issing som et hing, t hat t here was m ore t o t his t han m eet s t he eye. Thus, I broadened m y search t o include m ore and m ore cross- indust ry sources on product design, civil archit ect ure, and proj ect m anagem ent . I am not sure exact ly when, but wit h t im e, t he answer began t o evolve, and one day, a form began t o appear in t he fog. However, I do know when I becam e cert ain t hat I had t he answer and, at t he sam e t im e, t hat I also knew it s nam e: archit ect ural st yle. I had picked up a book in At lant a, Georgia, in 1997 in a bookst ore specializing in civil archit ect ure. The book was a com pilat ion of Germ an m anuscript s t hat had been t ranslat ed int o English. The original t ext s had been writ t en by a group of archit ect s in a period from 1828 t o 1847 at t he Universit y of Karlsruhe, Germ any. The book w as t it led, I n What St yle Should We Build? The Germ an Debat e on Archit ect ural St yle ( Herrm ann 1992) . While I was reading about t hese disput es, everyt hing st art ed t o fall int o place. These archit ect s were debat ing cont em porary archit ect ural st yle, but it was clear from t he discussion t hat t he Greeks had st art ed t his debat e t housands of years ago. I t t urns out t hat t his t hing called archit ect ural st yle is a pow erful design and com m unicat ion t ool t hat t he ent ire I T field has been m issing out on. I t was clear t o m e t hat we had not yet reached t he level of design com m unicat ion already in use m any years ago in ot her indust ries. Finally, I had found an effect ive and last ing way t o solve m y problem . I had seen proof t hat it works, and I even knew it s nam e. I knew where I needed t o go. Now I det erm ined t o get t here. That was 1997. Since t hen, a lot has happened. Over t im e, I used m y observat ions on archit ect ural st yle t o define a form t ailored for use in t he I T field, which I call I T- archit ect ural st yle. My colleagues and I also developed a part icular I Tarchit ect ural st yle, t he Convergent Archit ect ure, which has evolved and has been refined t hrough int ensive use over t he years. The Convergent Archit ect ure is a concret e applicat ion of I T- archit ect ural st yle t hat m akes up t he lion's share of t his book. First , however, I would like t o share wit h you som e of t he observat ions and analogies t hat helped m e not only com prehend archit ect ural st yle in general, but

-16-

Convergent Architecture

Chapter 1: IT-Architectural Styel

also underst and how it can be applied t o achieve m anifold benefit s across t he field of I T design and syst em developm ent . Before I get st art ed, it is im port ant t o not e t hat t he concept of I T- archit ect ural st yle appears t o be a logical and nat ural evolut ion in t he field of I T archit ect ure—it is in t he air. My early st art elaborat ing, developing, and pract icing I T- archit ect ural st yle has been encouraged by increasing evidence from respect ed sources t hat I am on t he right t rack. I n recent years I have seen t he t erm archit ect ural st yle m ent ioned repeat edly in t he I T cont ext , albeit briefly and at a cont em plat ive level. One not able reference here is t he " I nt roduct ion" t o t he Rat ional Unified Process ( Krucht en 1998) , w hich I can recom m end for it s concise int roduct ion t o I T archit ect ure in general. I n his book, Mr. Krucht en briefly m ent ions t he relevance of archit ect ural st yle as a viable I T- archit ect ural concept . I agree, of course, t hat an I T- archit ect ural st yle increases bot h t he uniform it y and underst andabilit y of designs. Krucht en and I are also in vehem ent agreem ent t hat an I T- archit ect ural st yle achieves t his, for exam ple, by opt im ally com bining pat t erns, t ools, descript ions, and fram ew orks t o bet t er support I T archit ect s. I t is now t im e t o t ake a m ore in- dept h look at I T- archit ect ural st yle bot h in t heory and at w ork. A Long H ist or y of Succe ss At a first glance, it is difficult t o recognize t he use of archit ect ural st yles in som e indust ries. This is because no indust ry uses archit ect ural st yle exact ly as anot her indust ry. Each has it s own t erm inology, it s own unique, cust om ary way of doing t hings. This m eans t hat archit ect ural st yle appears in various shapes and form s, m aking it som et im es difficult t o see parallels bet ween indust ries. However, t hese parallels—t he use of som e form of ident ifiable archit ect ural st yle—do exist . We will look at a few of t hese parallels in t he rest of t his sect ion t o bet t er underst and what archit ect ural st yle is and how it can significant ly im prove t he way we work in t he I T indust ry. Archit ect ural st yles have been around for t housands of years. For exam ple, Greek archit ect s spent hundreds of years perfect ing an archit ect ural st yle: t he I onic t em ple archit ect ure. Civil archit ect s consider t he Part henon in At hens t o be t he epit om e of t he I onic t em ple—m eaning t hat it is t he exem plary inst ance of an archit ect ural st yle. Over t he years, hundreds of archit ect s built hundreds of t em ples according t o t his st yle, each m aking his or her own cont ribut ion t o it s perfect ion over t im e. Each of t hese cont ribut ions w as t o t he clear advant age of t he next generat ion of archit ect s as well as t he benefact ors of each individual t em ple. I n m odern t erm s, we would call t his a win- win sit uat ion. I onic t em ple archit ect ure is not an isolat ed exam ple. Got hic[ 1] archit ect ure w as perfect ed in t he sam e m anner over hundreds of years. Each Got hic cat hedral, for exam ple, is an inst ance of t he Got hic archit ect ural st yle. The archit ect of each cat hedral based his or her com plex design on t he proven achievem ent s of ot her professional archit ect s who had used t he Got hic st yle t o build ot her cat hedrals. I n t urn, m any of t hese archit ect s m ade cont ribut ions t o t he Got hic st yle t o t he benefit of t he next generat ion. The archit ect ural st yle evolved, st ep by st ep, t hrough generat ions of highly skilled designers. No single designer, no m at t er how skilled, could have achieved t his feat alone. I f you ever have t he chance t o t ravel in Europe, it is fascinat ing t o visit and observe t he churches and cat hedrals bearing clear evidence of t he evolut ion of several dist inct archit ect ural st yles. For exam ple, early Got hic churches consist ed of basic point ed arches w it h t hick w alls, sm all

-17-

Convergent Architecture

Chapter 1: IT-Architectural Styel

windows, and low ceilings. They were pret t y dark and dreary. This was so because t he archit ect s of t hat period did not yet know how t o effect ively com bine high ceilings and large window s. Hundreds of years and hundreds of churches lat er, t he sam e st yle had evolved t o m anifest m agnificent vault ed ceilings, large w indows, and t hin walls support ed by flying but t resses on t he out side. Not re Dam e de Paris, t he Koelner Dom in Cologne, Germ any, and t he St rasbourg Munst er in France are prim e exam ples of highly evolved Got hic archit ect ure. Engineers st ill m arvel at t hese m ast erworks. None of t his would have happened wit hout t he cooperat ive cult ure of archit ect s cont ribut ing t o increm ent ally im prove t he archit ect ural st yle. Each inst ance of t he st yle, each Got hic st ruct ure, consist s of cont ribut ions accum ulat ed and refined over hundreds of years, all adding up t o significant engineering progress. From a m ore m odern perspect ive, t he sim ilar use of archit ect ural st yle can be observed in every m at ure engineering discipline, from boat design t o cit y planning, from airplane design t o aut om obile product ion. Prim e exam ples of archit ect ural st yle in t he aut om obile indust ry are t he roadst er, t he pickup t ruck, or t he Form ula One racing car. I n t he aerospace indust ry, we can easily dist inguish j et s, helicopt ers, or even Zeppelins as clear represent at ives of archit ect ural st yle analogous t o t he Got hic archit ect ure j ust described. A H ighe r Le ve l of Com m u nica t ion Not only does t he archit ect ural st yle define how t hings look—cat hedrals, cars, airplanes, and so on—it also oft en defines ot her crit ical design propert ies such as aerodynam ic feat ures, t olerances, and capacit ies. I n addit ion, it defines how t hese propert ies m ay be achieved dependably wit h part icular m at erials, t ools, and form s ( or pat t erns) . Whet her it needs t o define t hese aspect s, and how it precisely defines t hem , depends on t he part icular field. Moreover, where easily dist inguishable st yles t urn up depends on t he field. I n t he aut om ot ive indust ry, for exam ple, we recognize several dist inct st yles of m ot or design ( Ot t o, Diesel, or Wankel) , each m anifest ing an int ense focus on t he int ricat e perform ance and t herm odynam ic propert ies of int ernal com bust ion engines ( com pression rat ios, com bust ion cham bers, fuel m ixt ures) . The consist ent evolut ion of m ot or perform ance over t he past decades, wit h lit t le change in t heir ext ernal form , em phasizes t hat st yles also convey hard- t o- see design opt im izat ions, not j ust t he definit ion of ext ernal form .

An archit ect ural st yle expresses t he language and design cult ure t hat helps st akeholders at all levels t o com m unicat e at a higher, m ore effect ive level. All m at ure schools of art , engineering, and science have t heir own special languages t hat have evolved over years t o help expert s express t hem selves m ore accurat ely. I f you list en t o a group of surgeons conversing during an operat ion, you probably would not underst and m uch, but t hey are com m unicat ing in a highly effect ive m anner. They are versed in t he language of t heir t rade. Such languages are m ore highly developed, m eaning m ore expressive or m ore form alized, in som e fields t han in ot hers. Civil archit ect s have m ost act ively addressed t heir special language, as indicat ed by such t it les as " The Classical Language of Archit ect ure," " Classical Archit ect ure: The Poet ics of Order," or "A Pat t ern Language" ( Alexander 1977) , where t he gram m ar and vocabulary of various archit ect ural st yles are discussed. For exam ple, t erm s accurat ely describing st ruct ures such as arches ( archivolt , archit rave) and colum ns ( I onic, Doric, Corint hian) are t he words of an archit ect ural

-18-

Convergent Architecture

Chapter 1: IT-Architectural Styel

language. Correspondingly, t he organizat ion of st ruct ures wit h respect t o one anot her form s t he gram m ar of t he language: The rose window of a Got hic cat hedral is alw ays round and is placed above t he port al. These words and t he gram m ar are t hen used t o express com plet e st yles—Got hic, Rom anesque, I onic— j ust as st yles of writ ing, t heat er, and poet ry exist in lit erat ure. [ 2] The st yle is t he next higher level of design expression. I n an I T- archit ect ural st yle, t his t ranslat es t o, for exam ple, t he use of accurat e t erm s for com ponent st ruct ures and t heir relat ionships t o express som et hing t he archit ect considers t o be of higher value. I n t he Convergent Archit ect ure, such st ruct ures are it s convergent [ 3] organizat ions, processes, and resources ( OPRs) and t heir relat ionships. Processes and resources are m anaged by an organizat ion; a process consum es and produces resources, and so on. Toget her, and only t oget her, t hese charact erist ics lead t o t he high- level propert y of convergence in a syst em based on t he Convergent ( st yle) Archit ect ure. Clearly, t here is st ill m uch progress t o be m ade concerning t he language of I T archit ect ure. Today t he com m on language used by I T designers is very weak. Even t hough t hey oft en use t he sam e words, t hey are not com m unicat ing well. All t oo oft en, we experience I T design sit uat ions in which people have t o explain t he t erm s t hey use from ground zero. Such m eet ings can go on forever while m aking lit t le progress, and everyone has t o explain t heir basic w ords and gram m ar t o each ot her every t im e a new group convenes. View point s t hen change from one m eet ing t o t he ot her, so t he whole frust rat ing process st art s again. I t is not j ust t he rare or special t erm being discussed, but very fundam ent al concept s such as basic com ponent designs or role definit ions. I t is as if each designer had ent ered t he m eet ing having defined his or her ow n privat e t im e syst em . First , t he whole group m ust discuss and agree on t he t im e syst em before a sim ple t im e plan can be m ade. I nevit ably, each individual will define t erm s different ly. I t is no wonder t hat I T proj ect s are so expensive and high- risk. The agreem ent on a language, on a part icular st yle, is oft en m ore im port ant t han t he language it self. No archit ect ural st yle claim s t o be t he only way t o build som et hing, nor does it claim t o have found som e absolut e t rut h. An archit ect ural st yle is always a proposit ion. I t is put t ing a st ake in t he ground. I t is saying t hat people can build som et hing successfully if t hey agree t o work t his way. I n ot her words, t here is m ore t han one way t o skin a cat , and t here will always be several ways t o define an archit ect ure. However, t his did not keep civil archit ect s from agreeing on archit ect ural st yles, whet her Got hic, Rom anesque, or Renaissance, and t hen using and refining t hese st yles for hundreds of years. They underst ood t hat t he m aj or benefit s are at t ained as soon as an organizat ion agrees on an archit ect ural st yle, not beforehand. By t he sam e t oken, what large I T organizat ions need is less philosophical discussion regarding absolut e t rut hs and m ore agreem ent on an archit ect ural st yle. Thus, t o im prove t he present sit uat ion im m ediat ely, designers can st art by agreeing on a com m on basis; t hey can begin at t he level of an exist ing archit ect ural st yle. This provides a com m on reference fram e in which words and ot her crit ical design feat ures are defined accurat ely. Designers t hen begin com m unicat ing at an effect ive level and can w ork from t here. I n addit ion, using an archit ect ural st yle as t he basis for definit ions m eans t hat t he developers do not have t o convince t he whole world t hat t heir definit ion is t he correct one. Est ablishing a worldwide st andard, t hat is, a worldwide definit ion, for t he m any

-19-

Convergent Architecture

Chapter 1: IT-Architectural Styel

aspect s of archit ect ure is not som et hing t hat m ost designers have t im e t o do. Besides, it m ay be an im possible t ask anyway. This is one reason archit ect ural st yles exist in m ost fields. The archit ect ural st yle let s large com m unit ies of designers work m ore effect ively wit hout having t o wait for t he w hole world t o agree on som et hing. I n ot her w ords, t he st yle com plem ent s w orldwide st andards wit h st ylewide st andards. I t defines t he com m on dict ionary of a specific archit ect ural language. The language can be used across t im e, persons, and proj ect s t o com m unicat e bet t er. Needless t o say, t he design pat t erns m ovem ent and st andardizat ion work on com ponent m odels, such as J2EE/ EJB, have been a very significant st ep in t he right direct ion. However, som eone st ill has t o define exact ly what form s of t he pat t erns or com ponent s are being used and how t hey will work t oget her t o add relevant advant ages. As you will see, an I T- archit ect ural st yle does exact ly t his by incorporat ing t ools, t echniques, pat t erns, and com ponent st andards as part of it s language. I t t hen goes on t o refine t he language in addit ional im port ant areas. These addit ions enable, for exam ple, a m ore accurat e expression of such t hings as archit ect ural principles, developm ent life cycles, t ool int egrat ion, or t he relat ionships am ong proj ect , business, and syst em design. Once an organizat ion has agreed on an archit ect ural st yle as it s language of I T archit ect ure, it can m ove beyond im proved com m unicat ion in t he developm ent organizat ion t o im proved com m unicat ion bet ween all levels of t he business. For exam ple, t he Convergent Archit ect ure form alizes t he expression of business- I T convergence by defining convergent organizat ions, processes, and resources as part s of it s language. These elem ent s form a sort of archit ect ural gram m ar t hat has bot h business and t echnical significance. This m eans t hat business specialist s can use t hese elem ent s t o com m unicat e wit h t echnical specialist s, and vice versa. Misunderst andings and cult ure clashes are avoided from t he out set . For exam ple, when a designer and a business st rat egist discuss a billing process, bot h of t hem know exact ly what is m eant by a billing process. Once t his level has been achieved, t he next level is possible. This is where t he I T syst em graduat es from being a t ool for im plem ent ing business st rat egies t o an effect ive business opt im izat ion t ool. I n 1995, Dr. David A. Taylor explained how t his w orks in his book ent it led, Convergent Engineering. The Convergent Archit ect ure is t he I T- archit ect ural st yle t hat t hen t ransport s t hese concept s int o applied syst em design. I nt roducing an I Tarchit ect ural st yle t herefore is one of t he best invest m ent s an organizat ion can m ake t oward business opt im izat ion in t he I nform at ion Age. M or e t ha n a M a cr o Pa t t e r n Why don't we j ust call t he I T- archit ect ural st yle a m acro pat t ern or m et a pat t ern? The sim ple answer t o t his quest ion is: for t he sam e reason w e do not call a com ponent a m acro- obj ect . The best reason t o int roduce a new word is t o denot e im port ant differences. The word com ponent was defined in t he I T field t o dist inguish it from an obj ect or a m acro- obj ect . Alt hough com ponent s leverage obj ect t echnology, t hey add significant design aspect s such as com posit ion and deploym ent on t op. To use t he word obj ect t o refer t o bot h obj ect s and com ponent s would sim ply confuse t w o im port ant concept s. By t he sam e t oken, an I T- archit ect ural st yle is m ore t han a pat t ern. I t uses and consolidat es specific pat t erns, but not all pat t erns. I n addit ion, it com prises ot her developm ent aspect s such as com ponent st andards, m odeling languages, business design concept s, and t echnology m appings. I t even includes it s own st ream lined developm ent process. Thus, j ust as com ponent s accom pany and com plem ent obj ect t echnology, I Tarchit ect ural st yles leverage and com plem ent pat t erns.

-20-

Convergent Architecture

Chapter 1: IT-Architectural Styel

The N e x t Le ve l of D e sign An archit ect ural st yle const it ut es t he next level above applied archit ect ures. This level is t he place where design knowledge of all sort s is packaged t o be reused by m any individual archit ect ure proj ect s. I t is t he level where proact ive design preparat ion t akes place t hat enables design proj ect s t o get off t o a bet t er st art . This m eans t hat we now recognize t he following t hree levels of developm ent , beginning wit h t he archit ect ural st yle at t he t op and ending wit h t he finished syst em or const ruct ion.

ƒ

The a r chit e ct ur e . This is an inst ance of t he archit ect ural st yle, [ 4] t he applicat ion of t he st yle for a part icular sit uat ion. For exam ple, t he archit ect ure of Not re Dam e de Paris is an inst ance of t he Got hic archit ect ural st yle, t he archit ect ure of t he CAT900 series diesel m ot or is an inst ance of t he Diesel st yle m ot or archit ect ure, and t he archit ect ure of t he Travel Exchange port al is an inst ance of t he Convergent Archit ect ure st yle. Norm ally, t he chief archit ect or t he corporat e archit ect ure t eam leverages an archit ect ural st yle t o develop m any com pliant inst ances over long periods of t im e or across m any proj ect s in parallel. The syst e m or const r uct ion. This is t he end result , t he syst em or const ruct ion it self. There m ay be any num ber of syst em s or const ruct ions, each being an individual inst ance ( or incarnat ion) of t he archit ect ure. Exam ples are t he Not re Dam e de Paris cat hedral it self, each and every CAT900 series m ot or built , and release 2.0 of t he Travel Exchange port al. Each of t hese is t he result of an individual product ion proj ect t o const ruct som et hing according t o t he archit ect ure.

TE

ƒ

The a r chit e ct ur a l st yle . Exam ples of t his w ould be, Got hic ( civil) archit ect ure, t he Diesel ( m ot or) archit ect ure, and t he Convergent ( I T) Archit ect ure. This level is developed and m aint ained out side a part icular product ion proj ect .

AM FL Y

ƒ

An Eve r ybody- W ins Appr oa ch t o Qua lit y One of t he m ost im port ant aspect s of an archit ect ural st yle is it s built - in qualit y cont rols. The st yle will only survive if it offers t angible, long- t erm engineering value. I t s cont ribut ors are a diverse group of pract icing developers who carry out t heir day- t o- day business using t he archit ect ural st yle. I t is crit ical t o t heir success in real- world sit uat ions. The use of new concept s and t echnologies in t he st yle will not be accept ed wit hout first com plet ing am ple due diligence. The t em pt at ion of quick fixes or m arket ing- driven t echnology t rends[ 5] is reduced because t he designs m ust st and up t o m axim um scrut iny by qualit y- conscious peers. Developers gladly part icipat e in a perpet ual cycle of reuse, evaluat ion, and im provem ent because it is an everybody- wins sit uat ion. This is because everyone benefit s from im provem ent s in t he st yle, and every repeat ed applicat ion of t he st yle cont ribut es t o higher qualit y. This process of nonpart isan evolut ion helps ensure t hat t he archit ect ural st yle rem ains a high- qualit y engineering inst rum ent . One way t he archit ect ural st yle ensures an increasing level of repeat able qualit y is by prescribing propert ies of design. I n addit ion t o propert ies, it also m ay prescribe procedural aspect s of developm ent . I t is t he repeat ed use of t hese propert ies t hat dist inguishes an archit ect ural st yle from ad hoc approaches in t erm s of bot h recognit ion and qualit y. For exam ple, Got hic cat hedral archit ect ure st rict ly requires

-21-

Team-Fly®

Convergent Architecture

Chapter 1: IT-Architectural Styel

t he building t o be cruciform . I t also prescribes num erous form charact erist ics of it s port als and windows. These m andat ory charact erist ics const it ut e key elem ent s of t he archit ect ural st yle. This does not m ean t hat t he st yle is a st raight j acket for t he designer or t hat it dict at es every last det ail. However, t he m andat ory elem ent s, even when subt le, exist for good reasons: They increase qualit y for all users of t he st yle. Whet her t his qualit y is m easured on an engineering, aest het ic, or even a t heological scale depends on t he t arget group of t he st yle. An archit ect recognizes t he value of t hese m andat ory elem ent s and m akes creat ive adapt at ions only wit hin t he degrees of freedom t hey allow . This is why t he archit ect s of Got hic cat hedrals did not random ly m ix in st ylist ic elem ent s from Rom anesque archit ect ure. I f t hey had, t hey would have t aken unnecessary risks. I n t his respect , an archit ect ural st yle is also like a good recipe. You can m ake creat ive alt erat ions in m any areas, but t o arrive at t he int ended dish, you had bet t er pay at t ent ion t o t he advice in t he recipe, even if it appears t o be m inor at first glance. I f t he recipe says t o add a pinch of salt and you decide t o dum p in t he whole box of salt , t hen you have m issed t he point . The consequences of disregarding t he advice of a recipe are obvious t o us all. However, com plex syst em s—buildings, m ot ors, airplanes, I T syst em s—all possess subt le design elem ent s t hat are far from obvious. Oft en, t hese elem ent s m ust act in concert wit h ot hers across t he ent ire design t o produce t he desired effect , no single one of t hese elem ent s being visibly crit ical in it s ow n right . For exam ple, it t ook several decades, num erous com panies, and hundreds of engineers t o figure out how t o build m ot ors t hat did not knock and rat t le. The changes m ade were hardly visible in each new generat ion of m ot or. This is because t hey consist ed of hundreds of sm all changes at m any places in t he m ot or, which m ade a big difference only when t hey w orked t oget her. Last ly, it is im port ant t o not e t hat t hese consolidat ed effort s t o const ant ly im prove qualit y did not happen in single proj ect s, in single com panies, or in st andards organizat ions; t hey happened at t he everybody- wins level—at t he level of archit ect ural st yle. Evolut ion w it hout Re volut ion An archit ect ural st yle evolves cont inuously t o t ake advant age of t he best available t echniques and t echnologies. Ent ire com m unit ies of developers repeat edly creat e inst ances of t he st yle. Over t im e, sit uat ions arise wit hin t his com m unit y in which a developer is able t o m ake an im provem ent t o t he st yle it self. Norm ally, an im provem ent is first m ade in a part icular proj ect , for what ever reason. Aft er proving it self in t he field, t he im provem ent m ay be added t o t he st yle as a whole. This happens on a regular basis. I f it did not , t hen t he st yle would not be in use for very long. This is so because t he users of t he st yle expect it t o leverage t he best t echnologies available. Depending on t he field, t his evolut ion can be very rapid. Form ula One m ot ors, for exam ple, evolve at an ext rem ely rapid pace. A corresponding exam ple from t he Convergent Archit ect ure consist s of t he m any im provem ent s t o leverage new I nt ernet and com ponent st andards such as J2EE/ EJB or CORBA com ponent s. Oft en, t he variat ions m ade t o a specific archit ect ure, an inst ance of a st yle, are not general enough t o be candidat es for t he st yle it self. I nst ead, t hey are adapt at ions m ade by t he designer t o m eet t he special requirem ent s of t he part icular sit uat ion. No one Got hic church, for inst ance, is exact ly t he sam e as anot her. This is because every t own in which one was built had special requirem ent s and const raint s, such as t he availabilit y of building m at erials, m achines, and labor. The wishes of t he

-22-

Convergent Architecture

Chapter 1: IT-Architectural Styel

church com m unit y or bishop t o creat e som et hing special and unique also played an im port ant role. I t is im port ant t o not e t hat changes w ere not m ade t o t he st yle it self. I n fact , t he st yle support ed such effort s by freeing t he archit ect from t he st andard engineering problem s and allowing him or her t o be creat ive in com plet ely new areas. The archit ect ural st yle did not hinder creat ive design m odificat ions t o m eet t hese needs. I t sim ply defined a st andard reference fram e— not a norm at ive st andard—by w hich bot h developers and users of t he enhancem ent orient t hem selves. This brings us t o anot her point regarding st andards and archit ect ural st yles. An archit ect ural st yle is never finished unt il t he com m unit y of designers st ops finding im provem ent s for it or unt il it j ust goes out of st yle. The I onic t em ple is an exam ple of bot h t hese sit uat ions. First , it s archit ect ural st yle went out wit h t he dispersal of ancient Greek cult ure. The religious reasons t o build such t em ples becam e a rem nant of hist ory. However, t he Part henon is st ill considered t o be t he epit om e of an I onic t em ple. Const ruct ions based on it s archit ect ure w ere built hundreds of years lat er in Rom e, Paris, and even Thom as Jefferson's Virginia. [ 6] Each of t hese reproduct ions bears wit ness t o t he relevance and value of an accom plished archit ect ural st yle, which is reused as is, perfect ly fulfilling it s purpose each t im e.

There are also cases of archit ect ural st yles experiencing a renaissance by being react ivat ed int o t he act ive engineering m ainst ream . Oft en, it is sufficient for j ust a few param et ers t o change wit hin t he paradigm , such as t he availabilit y of cert ain m at erials, a new processing t echnology, or a shift in t he econom ic set t ings in order t o give t he st yle com plet ely new pot ent ial. The crash of t he Hindenburg in 1937, for exam ple, put an abrupt end t o t he first era of Zeppelin- st yle airships. The Zeppelin st yle, however, has now been revived and furt her evolved. Modern cargo airships are now being designed by several large consort ium s t o t ransport cert ain goods m uch m ore econom ically t han airplanes. These are cont inuat ions of t he Zeppelin archit ect ure—a clearly dist inguishable archit ect ural st yle. I f so m any persons are using and cont ribut ing t o t he archit ect ural st yle, t hen who defines and m aint ains it ? I refer here t o t he current owner of t he st yle. This is t he person or group of persons who are bot h respect ed pract it ioners in t he field and are willing t o m anage t he process of consolidat ing diverse input s, publishing new reference docum ent s, and inform ing all int erest ed part ies. This can be a t ricky sit uat ion because, conceivably, t w o part ies could claim concurrent ow nership t o a part icular st yle or t wo diverging branches of t he st yle. Such branches are a healt hy and nat ural consequence of evolut ion. To prevail over t im e, an archit ect ural st yle clearly m ust have an act ive owner or an owning group and cont ribut ors who cont inuously use and add value t o t he st yle. Addin g I nnova t ion w hile H e dgin g Risk s An archit ect ural st yle defines how st andards are best applied, as does any good archit ect ure. However, it hedges risks by providing an addit ional level of verified innovat ion above and beyond st andards. Risk is always associat ed wit h developm ent proj ect s. This is because designers m ust break new ground t o add value or t o build unique solut ions. Widely accept ed st andards do not provide com plet e syst em s; t hey are, at best , part s of a com plet e solut ion. The cost and risks due t o necessary innovat ion above and beyond st andards are usually

-23-

Convergent Architecture

Chapter 1: IT-Architectural Styel

ext rem ely high. This is especially t rue in t he I T indust ry, where int repid opt im ism oft en leads t o t he fiery deat h of proj ect s. An archit ect ural st yle hedges t hese risks by providing a level of innovat ion t hat has been developed and evaluat ed by m any expert s. I n ot her words, it low ers t he am ount of experim ent at ion necessary. I t also ensures t hat t he innovat ions preserve archit ect ural int egrit y and do not lead t o t he long- t erm problem s of ad hoc design.

Consider t he following scenario: The Triple- A Mot or Com pany want s t o develop t he m ost m odern diesel m ot or on t he m arket and has a few innovat ive ideas for t echnical im provem ent s on current ly available diesel m ot ors. Now, t he current norm at ive st andard for fuel inj ect ion in diesel m ot ors specifies t he use of m echanical inj ect ion, whereas m odern diesel m ot ors all use elect ronic inj ect ion t o achieve superior perform ance. I n ot her words, t he st andard says t o use m echanical inj ect ion, whereas t he archit ect ural st yle has already evolved t o elect ronic inj ect ion. I f t he Triple- A Mot or Com pany rem ains at t he level of t he st andard, it is no longer com pet it ive, and if it reinvent s elect ronic inj ect ion, it has added no value. Thus, inst ead of developing t he elect ronic inj ect ion, Triple- A uses t he design, t ools, and inst ruct ions of ot hers who have added t his ( nonst andard) innovat ion successfully t o t he diesel m ot or. Achieving t his level of innovat ion, oft en referred t o as t he indust ry st andard, is provided by t he archit ect ural st yle, not by t he st andard. At t his point , Triple- A can bet t er afford t o add it s own unique innovat ion, such as a new cylinder geom et ry, wit hout t aking on unnecessary risk . I f t hings are not working out wit h t he new, experim ent al cylinder geom et ry, TripleA can fall back im m ediat ely t o an indust ry st andard elect ronic inj ect ion m ot or. By doing t his, Triple- A has hedged it s risk. I f t hings go well, t he new m ot or set s a new level of indust ry st andard. Som e day, t his feat ure m ay even becom e part of an official int ernat ional st andard. I n ot her words, if t he experim ent s fail, t hen Triple- A st ill has a m arket able fallback, ensuring t hat it can deliver and t hat it will live t o t ry again anot her day. This scenario em phasizes t he im port ant role archit ect ural st yles play in helping developers use st andards effect ively t o m anage risk and m aint ain a fut ure- safe archit ect ure. There is an addit ional advant age: Since Triple- A will build m any generat ions of diesel m ot ors in t he fut ure involving m any different design proj ect s, it defines and m aint ains it s own corporat e archit ect ural st yle. The st yle provides st ipulat ions regarding crit ical design and process feat ures, such as it s new cylinder geom et ry. By using t he corporat e st yle, proj ect s are less likely t o diverge from t he pat h of archit ect ural int egrit y. I n addit ion, each proj ect can bet t er reuse not only design know- how, but also part s, t ools, infrast ruct ure, and procedures. This reduces bot h risks and cost by im proving t he overall qualit y of design inform at ion. The I m por t a nce of St yle in I T Ar chit e ct ur e Thus, w hy is it t hat archit ect ural st yles are not yet w idely used in t he I T indust ry? This is m ost likely due t o t he relat ive yout h and fledgling st at us of t he I T indust ry as com pared wit h ot hers—we j ust have not got t en t o it yet . Cert ainly, t echnologies and t echniques are being handed down across generat ions of I T engineers. This happens t oday in t he form of pat t erns, fram eworks, m et hodologies, and blueprint s. However, t his is not happening at t he level it could—not at a level com m ensurat e wit h t he archit ect ural st yles found in ot her indust ries and not at t he level dist inct ly possible t oday in t he I T indust ry.

-24-

Convergent Architecture

Chapter 1: IT-Architectural Styel

There is a second reason of equal im port ance: You cannot see t he 90 percent of t he design ( or lack t hereof) of I T syst em s wit hout t ools. I n cont rast t o every ot her t ype of syst em or const ruct ion, you cannot st and in front of a running I T syst em and see how it w as designed. Hum ans do not have sense organs for t he virt ual worlds of I T. The only t hing a hum an can easily j udge is t he hum an int erface of an I T syst em . This is t he t ip of t he iceberg. Many a syst em has been delivered w it h adequat e ( or inadequat e) user int erfaces but wit h a design and im plem ent at ion m ore charact erist ic of a t im e bom b t han anyt hing else. The problem is t hat you cannot walk int o an I T syst em like you can walk int o a house or a cat hedral and experience, wit h eyes and ears, aest het ic pleasure or easily observe m any part s of it s st ruct ure. This is also t he reason poor design oft en goes unnot iced in t he t radit ional I T indust ry. This is part icularly disconcert ing because I T syst em s are alm ost pure design. Aside from t he hardware, few raw m at erials are required t o produce and run I T syst em s. Even m ore unusual, t here is virt ually no raw m at erial cost t o reproduce soft ware. Essent ially, design work dom inat es t he cost of building and m aint aining soft w are syst em s.

The fact t hat I T syst em s are design- int ensive virt ual worlds m eans t hat m odels and t ools t ake on a part icular im port ance. I T developm ent t ools are t he only m eans for a hum an t o see and m anipulat e t he I T archit ect ure effect ively. There is a lot of room for im provem ent here not only in t he use of t ools, but also in t he t ools t hem selves. To ensure t he effect ive visualizat ion and m anipulat ion of it s specific virt ual world, an I T- archit ect ural st yle m ust address t he area of t ools and t heir use. The t ools will evolve wit h t he st yle t hat m akes t hem m ore effect ive wit h each generat ion. I ronically, ot her indust ries have been m ore aggressive in t heir m ove t o com put er- aided design ( CAD) t ools t han t he I T indust ry it self. This sit uat ion is especially baffling because before t he advent of CAD t ools, t hese indust ries could at least physically see and feel t heir prot ot ypes and const ruct ions. This is not t he case wit h t he I T indust ry. Wit hout t he proper design t ools, a developer of large- scale syst em s is pract ically blind. The result of t his blindness is easy t o see in t he problem at ic ad hoc archit ect ures t hat plague large organizat ions t oday. Sooner or lat er, t he increasingly crit ical role of I T will force t hese organizat ions t o m ove t o an I T- archit ect ural st yle t hat defines t ools t o visualize and m anipulat e effect ively all levels of design. Only wit h such t ools will an organizat ion finally be able t o view and verify it s I T- archit ect ural st yle and t hus it s archit ect ural int egrit y. To dat e, t he open- source UNI X and Linux com m unit y has achieved t he m ost significant st ep in t he direct ion of archit ect ural st yle in t he I T world. The evolut ionary developm ent approach t o Linux offers undisput ed proof of t he benefit and product ivit y of t he everybody- wins sit uat ions I associat e w it h archit ect ural st yle. However, in t he I T world, t here is m uch m ore pot ent ial in archit ect ural st yle t han anyt hing current ly available. This is why I am reluct ant t o call UNI X or Linux an archit ect ural st yle despit e t heir success. I could live w it h calling t hem a st rong forbearer and a case in point of m any advant ages prom ised by I T- archit ect ural st yles. I n t he following chapt ers I will define what I consider t o be t he feat ures and t he pot ent ial of a m odern I T- archit ect ural st yle. My colleagues and I consider I T- archit ect ural st yle t o const it ut e a nat ural and inevit able st ep in t he evolut ion in t he I T indust ry. I will not j ust leave you wit h t his assert ion and som e hist orical analogies; I will back t his up in lat er chapt ers wit h a concret e I T- archit ect ural st yle, t he Convergent Archit ect ure, as proof of m y

-25-

Convergent Architecture

Chapter 1: IT-Architectural Styel

convict ion. Having said t his, I reit erat e t hat I cert ainly have not perfect ed t he universal definit ion of I T- archit ect ural st yle or even arrived at t he epit om e of a single I T- archit ect ural st yle. However, I am convinced t hat we are on t he right t rack and cont inue gaining experience wit h an ever- increasing num ber of t alent ed designers. Excit ing progress is already being m ade wit h t he Convergent Archit ect ure, which m akes up t he lion's share of t his book. My int ent ion in t his book is, in fact , not at all a debat e on I T- archit ect ural st yle in general. My prim ary goal is t o explain how pragm at ic advant ages can be achieved t oday wit h t he Convergent Archit ect ure. Wit h it , I hope t o convince you of t he virt ues of I Tarchit ect ural st yle and win you as a fellow designer in a rewarding cult ural experience along t he road t o t he next generat ion of I T syst em s. [ 1]

Definit ion from t he Am erican Herit age Dict ionary: " Of or relat ing t o an archit ect ural st yle prevalent in West ern Europe from t he 12t h t hrough t he 15t h cent ury and charact erized by point ed arches, rib vault ing and flying but t resses. Of or relat ing t o an archit ect ural st yle derived from m edieval Got hic." [ 2]

A sim ilar analogy can be m ade wit h m usic.

[ 3]

Many aspect s of convergence will be discussed in det ail in lat er chapt ers. Essent ially, it m eans t he alignm ent of business and I T m odels int o one com m on, synchronized m odel. [ 4]

This use of t he word archit ect ure conform s wit h m any accept ed definit ions and t axonom ies of I T archit ect ure. For a good definit ion, see I EEE ( 2000) . [ 5]

Market ing- driven designs conceived t o creat e or capit alize on a t rend in t he m arket place irrelevant of t he m at urit y or long- t erm cont ribut ion of t he design. Analogous t o m any prêt - à- port er fashion t rends in t he clot hing indust ry. [ 6]

The Virginia St at e Capit ol is described as t he " first adapt at ion of a t em ple for a m odern public building not only in Am erica, but in t he world" ( Girouard 1963) .

D e sign in g a n I T- Ar ch it e ct u r a l St yle Thus far I have int roduced archit ect ural st yle in general, m ost ly from a hist orical perspect ive. I t is now t im e t o m ove t o t he present - day sit uat ion and concent rat e on I T- archit ect ural st yle from t he perspect ive of soft ware design. I n t his sect ion I out line a design for any I T- archit ect ural st yle. The Convergent Archit ect ure const it ut es a part icular I T- archit ect ural st yle. How ever, any ot her I T- archit ect ural st yle m ay be form ulat ed or enhanced according t o t he design present ed here. First , since everyone likes short , one- sent ence sum m aries, no m at t er how broad t he field, I will begin wit h a condensed phrase for t he concept of archit ect ural st yle t hat includes I T- archit ect ural st yle:

An archit ect ural st yle conveys t he principles and t he m eans t o m ost effect ively achieve a design vision.

-26-

Convergent Architecture

Chapter 1: IT-Architectural Styel

The basic concept of an I T- archit ect ural st yle also can be derived from t he widely accept ed definit ion of I T archit ect ure est ablished by t he I EEE Com put er Societ y ( I EEE 2000) : " Archit ect ure is t he fundam ent al organizat ion of a syst em em bodied in it s com ponent s, t heir relat ionships t o each ot her and t o t he environm ent , and t he principles guiding it s design and evolut ion." Based on t his definit ion, it can be said t hat An archit ect ural st yle is a fam ily of archit ect ures relat ed by com m on principles and at t ribut es. An I T- archit ect ural st yle is bot h a holist ic and a specific approach t o I T archit ect ure. I t is holist ic in t hat it covers t he ent ire soft ware life cycle, including proj ect design and t ool design aspect s. I t is specific in t hat it consolidat es and int egrat es t he m any st ruct ural, procedural, and descript ive aspect s t hat have been addressed as separat e ent it ies in t radit ional m et hodologies. Every experienced developer or proj ect m anager has at som e point suffered t hrough t he int egrat ion and coordinat ion of such crit ical elem ent s as t ools, pat t erns, com ponent t echnologies, and m et hodologies, j ust t o nam e a few. These t hings are int im at ely relat ed t o each ot her, and t o work well t oget her, t hey m ust be considered t oget her, as pieces of a whole—holist ically. Once t his has been achieved, t he st ruct ure, relat ionships, and applicat ion of each of t he pieces m ust be sim plified by being as specific as possible about it s nat ure and it s use. I n ot her words, t he I T- archit ect ural st yle addresses bot h breadt h and dept h. I t t ackles t he problem of t he " big pict ure" while being specific about t he part s of t he big pict ure. This is im port ant in t oday's com plex world of specialist s: Som ebody has t o specialize in t he relat ionships bet ween all t he specialt ies—som ebody m ust specialize in t he big pict ure. This role can be com pared wit h t hat of a com poser. The com poser focuses on creat ing a ( whole) concert o t o be played by m usicians using ( specific) inst rum ent s. Every experienced developer knows how difficult it is t o m ake all t he part s of an I T developm ent work t oget her in concert . Defining and im plem ent ing such aspect s as t he right process in conj unct ion w it h t he effect ive use of com ponent st andards, pat t erns, t ools, and im plem ent at ion t echnologies are daunt ing t asks even for expert s. Many a proj ect has m et it s dem ise by at t em pt ing t o m ake all t hese t hings work t oget her while at t he sam e t im e t rying t o develop a syst em —like t rying t o com pose a concert o before underst anding t he m usical inst rum ent s. The proact ive definit ion of t he big pict ure and inst ruct ions on how it is applied specifically across m any proj ect s are not j ust desirable; t hey are crit ical for large soft ware organizat ions. The breadt h and dept h covered by an I T- archit ect ural st yle enable even t he best I T organizat ions t o achieve higher levels of effect iveness and ret urns. For exam ple, consider t he long- await ed breakt hroughs due t o obj ect t echnology, m any of which have eluded t he ent ire indust ry for years. Cont rary t o what is oft en writ t en in t he I T t abloids, it is not t he fault of obj ect t echnology t hat m any of t hese breakt hroughs have not yet been realized; rat her, obj ect t echnology has been a vict im of ad hoc archit ect ure. I n ot her w ords, t he failure is due t o a reluct ance on t he part of com panies t o address t ough I T archit ect ural issues. Just as an apple t ree will not bear fruit if it is plant ed in t he desert , t he advant ages of obj ect t echnology cannot be cult ivat ed wit hout t he proper I T environm ent . An I Tarchit ect ural st yle defines t his environm ent . I t defines how reuse is t o be handled in t he ent ire developm ent life cycle across all proj ect s in an ent erprise. The highlevel ret urns due t o reuse, j ust t o nam e one advant age of obj ect t echnology, can

-27-

Convergent Architecture

Chapter 1: IT-Architectural Styel

now occur realist ically in t he cont ext of t he I T- archit ect ural st yle discussed in t his book.

This brings m e t o t he inevit able quest ion of whet her t he breadt h- and- dept h approach of an I T- archit ect ural st yle is realist ic. This quest ion oft en arises because breadt h, or holist ic, is oft en confused wit h generalit y. Breadt h does not m ean t hat t he I T- archit ect ural st yle is com plet ely general in nat ure and t hus of lim it ed use in pract ice. This would conflict wit h t he requirem ent t hat it be specific. Breadt h m eans t hat it coordinat es a wide spect rum of act ivit ies and st ruct ures. Specific m eans t hat it does t his dow n t o a level t hat is det ailed enough t o be applied effect ively and rapidly. Can t his be achieved while st ill being useful for diverse syst em s across ent ire organizat ions or dom ains? Yes, it can. I n fact , t his is what good archit ect s achieve in all indust ries. I t requires one of t he m ost im port ant skills of an I T archit ect : t he skill of abst ract ion. Over t im e, t he designers of t he st yle recognize sim ple, w idely applicable solut ions t hat can be used t o solve specific problem s. Design pat t erns are one exam ple of such useful design abst ract ion. Carefully select ed design abst ract ions are t hen coordinat ed as a w hole t o form an I T- archit ect ural st yle. This cont inuous process of abst ract ion, select ion, and specific coordinat ion is param ount . More form ally, it can be said t hat an I Tarchit ect ural st yle provides a useful set of reasonable alt ernat ives—not all alt ernat ives—and coordinat es t hem t o work w ell t oget her. This can be achieved at a level t hat m eet s t he needs of ent ire dom ains and ent ire organizat ions. The Convergent Archit ect ure is m y proof. An exam ple scenario from a m at ure indust ry should m ake t his point m ore obvious. Suppose an airplane m anufact urer want s t o build t he next generat ion of planes. I t is clear t hat an archit ect ural st yle exist s for each of t he broad areas of propeller planes, j et planes, and helicopt ers. Each of t hese archit ect ural st yles support s an ent ire indust ry. A single m anufact urer uses one of t hese st yles, not all t hree at once. Our part icular m anufact urer envisions building t he best j et planes on t he m arket . Even t hough a new generat ion or new m odel of plane is being built , t he m anufact urer will st art wit h t he exist ing j et - plane st yle. The designers do not st art by considering all alt ernat ives; inst ead, t hey st art m ore effect ively by considering t he reasonable alt ernat ives offered by t he st yle. For exam ple, t he st yle does not offer t hem t he alt ernat ive of a helicopt er propeller on t op of a j et plane. Sure, t his is im aginable, but it has obvious drawbacks. The reason a j et - plane st yle om it s t his as a viable alt ernat ive is evident . However, t housands of m ore subt le design decisions, each expressed by t he reasonable alt ernat ives in t he st yle, are far from obvious. Such t hings as m at erial choices, t hrust requirem ent s, and t he int im at ely relat ed guidelines for shape and weight dist ribut ion are t he result of m illions of dollars of research and experim ent at ion over m any decades. The j et - plane st yle helps t he designers proceed wit h a high ret urn on invest m ent t o build t he next generat ion of j et aircraft . However, t his st yle w ill not help t hem build a helicopt er—t hat is a com plet ely different anim al, even t hough bot h of t hem fly. More im port ant , if t he j et - plane designers want t o use liquid hydrogen as a fuel inst ead of st andard aviat ion fuel, t hey will have t o m ake m odificat ions t o t he st yle. The st yle helps t hem w it h all t he rest of t he decisions, but it does base it s design on t he reasonable assum pt ion t hat t he st andard fuel will be used. I n cont rast , it does not prevent t he designers from m aking alt erat ions for liquid hydrogen in a specific inst ance of t he st yle.

-28-

Convergent Architecture

Chapter 1: IT-Architectural Styel

By com parison, if one looks at t he I T indust ry t oday, one observes a whole lot of j et planes wit h helicopt er propellers on t op. This is so because designers are not yet working at t he level of archit ect ural st yle. I nst ead, t hey reinvent , beginning at an ext rem ely low level each t im e. I t does not help if t hey can buy expensive com ponent s from t he m arket place—t he propellers and t urbines of t he I T w orld—if t hese are not applied properly. Wit hout an I T- archit ect ural st yle, t he developers cannot leverage t he m illions invest ed by ot hers in experim ent at ion and research. They are unaw are of t he ext rem ely subt le but decisive design decisions m ade in previous, very sim ilar designs. They are bound t o repeat a lot of cost ly m ist akes. The bot t om line is t hat m ost product ion I T syst em s in large ent erprises will rem ain at t he level of init ial experim ent at ion—t he experim ent al prot ot ype—unt il an I Tarchit ect ural st yle is int roduced. Nobody ever built a m odern j et plane wit hout using an exist ing archit ect ural st yle as a st epping st one. The sam e logic will apply for I T syst em s in t he fut ure. The I T- archit ect ural st yle explicit ly t arget s t he problem of unnecessary com plexit y in I T archit ect ure. I t sim plifies t he design as well as developm ent work by showing why t hings are done and how t hings w ork t oget her in t he overall big pict ure. I t achieves t his by st art ing from it s basic principles. From t hese principles, it derives, j ust ifies, and explains each level and part of an archit ect ure, including process and t ool aspect s. This m eans t hat t he concept s of I T archit ect ure can be t aught , or at least clearly explained, t o key individuals at all levels of an ent erprise—st art ing wit h t op- level m anagem ent . These concept s are t hen applicable t o not j ust one, but all syst em s and designs using t he archit ect ure, such as t he ent ire I T of a m aj or organizat ion. Based on t heir com m on knowledge of w hy t hings are done, t he proper persons can be act ively involved at each level of design. This m eans t hat bet t er decisions are m ade, syst em s becom e m ore effect ive, and risks are rem oved from developm ent . This also m eans t hat I T- archit ect ural st yle is m ost valuable when used as t he basis for ent ire I T infrast ruct ures. Alt hough it can be used for individual proj ect s, t he m ost com pelling reason t o int roduce an I T- archit ect ural st yle is it s abilit y t o support archit ect ural int egrit y across m any proj ect s. This is so because it replaces m any ad- hoc designs wit h a single, well- underst ood st yle. I t s holist ic approach t o t he soft ware life cycle enables I T m anagers and developers t o base ent ire I T landscapes on t he st yle and t o evolve such landscapes in a cont rolled m anner over long periods of t im e.

Get t ing down t o det ail, t he rem aining sect ions of t his chapt er define t he feat ures and principles of any I T- archit ect ural st yle. This set s t he st age for t he rem aining chapt ers of t his book, which det ail a concret e archit ect ural st yle, t he Convergent Archit ect ure. Chapt er 8 t hen shows, st ep by st ep, how an act ual inst ance of t he st yle is creat ed and used in a concret e developm ent sit uat ion. The Four Fe a t ur e s of a n I T- Ar chit e ct ur a l St yle An I T- archit ect ural st yle com prises four high- level feat ures, or layers. These feat ures have been dist illed out of observat ions from diverse I T archit ect ure proj ect s over t he last decade. They have been ident ified as crit ical t o t he success of an I T- archit ect ural st yle. I n addit ion, several principles are deem ed part icularly im port ant t o t he designer of any I T- archit ect ural st yle. These are also covered in

-29-

Convergent Architecture

Chapter 1: IT-Architectural Styel

t his sect ion. Needless t o say, t he process of analysis and evolut ion of t hese concept s cont inues. An I T- archit ect ural st yle fulfills it s purpose by im plem ent ing t hese four feat ures.

1. An archit ect ural m et am odel 2. A full- life- cycle developm ent m odel 3. A full- coverage t ool suit e 4. Form al t echnology proj ect ions

Th e Ar ch it e ct u r a l M e t a m ode l The archit ect ural m et am odel is t he t op- level m odel. I t is a m et am odel, m eaning t hat when applied, it produces or influences anot her m odel as it s result . I n t his part icular case, t he archit ect ural m et am odel influences pract ically every decision m ade in t he ent ire archit ect ure. I t does t his by defining t he vision and principles of t he archit ect ure. I t set s t he fundam ent al j udgm ent crit eria for every design decision, analogous in m any ways t o a const it ut ion, which set s t he j udgm ent crit eria for legal decisions. The m et am odel j ust ifies w hy we do t hings t he w ay we do t hroughout t he archit ect ure and provides t he basis for individuals t o m ake t he proper decisions at all levels. I t is t he reference fram e in which t he archit ect ure is refined and evolved over t im e. I t also defines under which const raint s such refinem ent and evolut ion t ake place. The principles in t he archit ect ural m et am odel can be seen as t he basis for t he laws of t he archit ect ure. These principles describe t he im port ant high- level vision and goals of t he st yle, and t hey do t his in a way t hat can be underst ood by a large, diverse audience. This is im port ant from t he perspect ive of archit ect ural int egrit y because only persons who underst and where laws com e from norm ally w ill follow t hem or even change t hem in a coordinat ed m anner. I n ot her words, it perm it s people t o st art com m unicat ing in t erm s of t he vision and t he principles t hat det erm ine it s design charact er—t he elem ent s charact erist ic t o t he part icular st yle. This level of com m unicat ion is key t o achieving a set of com m on goals. For exam ple, t he long- t erm vision of convergence in t he Convergent Archit ect ure has a significant im pact on all levels of it s design, it s developm ent process, and it s use of t ools and t echnology. Once t he concept of convergence has been underst ood, st akeholders can see and com prehend m ore easily how t he ot her layers of t he st yle achieve t his vision. By underst anding t he principles driving design decisions, people are put in cont rol of t echnology inst ead of t echnology cont rolling t hem . They begin t o underst and and see how t echnology is being applied in t he cont ext of a st yle t o realize it s principles across any num ber of proj ect s. They begin t o perceive t he im port ant role t hey play and becom e m ore involved in t he creat ive im provem ent of t he design. This is t he first im port ant st ep t oward creat ing a design cult ure of people who share a com m on sense of st yle. Having a shared cult ure and a shared sense of st yle is t he best way, if not t he only way, t o achieve long- t erm archit ect ural int egrit y.

A few analogies m ay serve t o illust rat e t he significance of t he archit ect ural m et am odel. Good exam ples of t his m et alevel are t he Bible, t he Koran, t he

-30-

Convergent Architecture

Chapter 1: IT-Architectural Styel

TE

AM FL Y

Com m unist Manifest o, or t he Unit ed St ates Const it ut ion. Each of t hese defines specific visions, principles, and ident ifiable elem ent s of st yle for religion or for governm ent . The m ere success of t hese pillars of religion and governm ent is evidence enough t hat t his level of form al com m unicat ion is necessary in m any cases and at least advant ageous in ot hers. The fact t hat we st art at t his level in an I T- archit ect ural st yle m ay rub som e persons t he w rong way at first sight ; how ever, we are j ust dealing wit h realit y. Beliefs, whet her t hey be religious, polit ical, or archit ect ural, are t he only way t o bind persons int o a st rong cult ure over long periods of t im e—in t his case int o a cult ure of solid I T archit ect ure. People get em ot ionally involved in t heir beliefs, not in t heir knowledge. The I T indust ry is no except ion t o hum an nat ure. For exam ple, t he com m only cit ed " I BM cult ure" and t he " Microsoft way" bind people by t he beliefs and principles t hey share. They are not bound by t heir t echnical knowledge, which could be applied at eit her com pany. I n civil archit ect ure, a prim e exam ple of a large group sharing com m on principles is t he Bauhaus school of archit ect s. Bauhaus began in Europe around 1919 ( Drost e 1998) and rem ained act ive in t he Unit ed St at es t hrough t he 1950s, where it gave rise t o t he I nt ernat ional St yle of civil archit ect ure ( Heyer 1993) . Bauhaus produced ast onishing works of archit ect ural and product design, m ost of which are st ill in m ainst ream use. The shared set of ident ifiable principles helped t hese groups of individuals work t oget her, over long periods of t im e, t o achieve a com m on goal. The archit ect ural m et am odel serves t his purpose in I T archit ect ure. A precise exam ple at t he level of an archit ect ural m et am odel from t he Bauhaus school was t heir vision t o harm oniously unit e form and funct ion in t heir designs. I n ot her words, t hey believed t hat an aest het ically pleasing form should not be som et hing added aft er t he st ruct ural engineering is finished. Their slogan was " Art and t echnology, t he new unit y." Essent ially, t his m eant t hat every design elem ent could be st ruct urally funct ional while at t he sam e t im e cont ribut ing t o a pleasing form . This was a real challenge, but t he Bauhaus school of designers believed t hat it should be done, and t hey succeeded. Their achievem ent of t his vision and t heir cont ribut ion t o archit ect ure and product design rem ain undisput ed t o t his day. A corresponding exam ple from t he archit ect ural m et am odel of t he Convergent Archit ect ure is it s long- t erm vision of convergence. Essent ially, convergence says t hat business and I T m odels can be unit ed int o one com m on m odel. This vision, which also can be form ulat ed as a set of principles, m ot ivat es and j ust ifies m any decisions t hroughout all levels of t he Convergent Archit ect ure, and it is responsible for m any of it s m ost recognizable elem ent s of st yle. The archit ect ural m et am odel helps avoid risk by clearing up pot ent ial m isunderst andings and disagreem ent s early. Using t he archit ect ural m et am odel, t he chief archit ect put s a st ake in t he ground and defines a clear, long- t erm direct ion—t he archit ect ural vision—for an ent ire organizat ion, not j ust for one proj ect . This ext rem ely im port ant st ep is carried out by any professional civil archit ect at t he out set of a m aj or undert aking. I t is im port ant for t wo reasons. First , t he chief archit ect m ust have a long- t erm st rat egy and com m unicat e it clearly at all levels of an organizat ion. Wit hout such a long- t erm st rat egy, t he proliferat ion of ad hoc archit ect ure, bot h at business and I T levels, cannot be avoided. Second, if t he st akeholders are not clearly inform ed and in agreem ent regarding t he st rat egy, big problem s will arise lat er. The lat er t hese problem s arise, t he worse t hey are. Take a look at cit ies around t he world t o see clear proof of t his point . To cit e a couple of posit ive exam ples, bot h Paris and Washingt on, D.C., owe m uch of t heir last ing beaut y first t o a chief archit ect wit h a clear, long- t erm vision and second t o st akeholders who j oined in and support ed t his vision over m any

-31-

Team-Fly®

Convergent Architecture

Chapter 1: IT-Architectural Styel

years. Wit hout t he clear archit ect ural vision, neit her of t hese im pressive, last ing achievem ent s in civil archit ect ure would have occurred. A clear archit ect ural vision is part icularly im port ant wit h respect t o I T syst em s. This is so because, cont rary t o civil archit ect ure, t he soundness of an I T syst em is not clearly visible t o anyone who cares t o look. The st at e of t oday's I T syst em s bears am ple evidence of t he problem s t hat creep up behind t he scenes due t o an unwat ched archit ect ure. The archit ect ural m et a- m odel is t he m ost im port ant st ep t ow ard resolving t his problem : I t t ells t he st akeholders first t hat t here is som et hing t o look for and t hen, in principle, what it should look like. The rest of t he archit ect ural st yle picks up at t his point and provides t he necessary det ail. I t is clear t hat if an organizat ion cannot agree on t he general principles of t he archit ect ural m et am odel, t hen agreeing at every ot her level will be an even bigger problem . This m eans t hat t he only way t o avoid t he problem s of ad hoc archit ect ure is t o agree on an archit ect ural st yle, beginning wit h t he basic principles in t he archit ect ural m et a- m odel.

Th e Fu ll- Life - Cycle D e ve lopm e n t M ode l The second- level m odel is t he developm ent m odel, and it defines how we achieve t he vision and fulfill t he principles expressed in t he archit ect ural m et am odel. I t form ulat es and t ransport s principles int o concret e st ruct ures, such as com ponent s and developm ent organizat ions, as w ell as procedures, such as t he developm ent process. These st ruct ures and procedures are t he vehicle of t he archit ect ural st yle. Only wit h t he exist ence of t he archit ect ural m et am odel is it possible t o define appropriat e developm ent st ruct ures. Let 's ret urn t o t he exam ple from t he preceding subsect ion, where we saw t hat t he U.S. Const it ut ion is at t he level of t he archit ect ural m et am odel. At t hat level, it expresses principles such as equalit y and t he presum pt ion of innocence. The vehicle of t hese principles, corresponding t o t he developm ent m odel, is t he j udicial branch of t he U.S. governm ent . The concret e st ruct ure and t he procedures of t he ent ire j udicial syst em are derived from t he principles in t he U.S. Const it ut ion. Essent ially, it would be im possible t o set up an effect ive j udicial syst em w it hout t he Const it ut ion. By t he sam e t oken, it is im possible t o set up a highly effect ive developm ent m odel wit hout t he archit ect ural m et am odel.

Sim ilarly, referring again t o t he Convergent Archit ect ure as an exam ple in t he I T field, t he developm ent m odel defines t he specific st ruct ural feat ures, such as Convergent Com ponent s for OPRs, wit hin t he archit ect ure. I n addit ion, a specific proj ect organizat ion and developm ent process are defined at t his level t o effect ively m eet t he part icular requirem ent s of t he archit ect ural m et am odel. For exam ple, a specific inst ance of t he Rat ional Unified Process ( RUP) is defined t o m ost effect ively prepare and erect convergent syst em s. Toget her, t he specific st ruct ures and procedures are t he prerequisit e for a specific, highly effect ive t ool environm ent , t he j ob of t he next layer of an I T- archit ect ural st yle. The m anaged evolut ion of an I T infrast ruct ure w ould be very difficult wit hout t he developm ent m odel. What , for inst ance, w ould happen if developers unilat erally changed fundam ent al design and developm ent st ruct ures in individual proj ect s? When t hings such as com ponent m odels, t echniques, and t ools are defined unilat erally in individual proj ect s, ad hoc archit ect ure is t he inevit able result .

-32-

Convergent Architecture

Chapter 1: IT-Architectural Styel

Wit hout t he developm ent m odel, such changes occur aut om at ically and unint ent ionally. There is no effect ive way for proj ect m anagers or developers t o synchronize t hem selves across proj ect s wit hout a com m on developm ent m odel. The only w ay ad hoc dilut ion of an archit ect ure can be avoided is t o provide t he lead designers of proj ect s wit h a developm ent m odel. I f fundam ent al st ruct ural changes do need t o be m ade, for inst ance, t hen t hey are m ade relat ive t o t he com m on m odel as used by all proj ect s. Expert s can t hen properly assess t he im pact on all designs, syst em s, and organizat ions, bot h present and fut ure. At t his point , a solid basis for a decision founded on dependable inform at ion exist s. I n addit ion, once decisions t o m odify t he archit ect ure are m ade, t he m igrat ion of every aspect of t he archit ect ural st yle can be planned and coordinat ed properly. Above all, such decisions are not m ade in an ad hoc m anner by, perhaps, t he wrong persons. This is t he m ost im port ant st ep t oward m anaged syst em evolut ion. The developm ent m odel is very different from generalized design m et hodologies in t hat it is concerned only w it h aspect s specific t o t he part icular I T- archit ect ural st yle, not wit h generalized advice. For exam ple, it should not present a discourse com paring various pat t ern approaches, developm ent process alt ernat ives, or com ponent m odels. I t should be as specific as possible, t elling t he developers which processes, pat t erns, and com ponent s t o use and, concisely, why t his choice was m ade. Whenever design opt ions are provided, t hen precise decision crit eria should be available as t o when a given opt ion applies. This is so because t he probabilit y of ad hoc and incom pat ible const ellat ions increases wit h t he num ber of unclear or com pet ing alt ernat ives. To ensure adequat e coverage ( dept h and breadt h) , t he following t hree fundam ent al t hem es should be addressed by t he developm ent m odel: ƒ

ƒ

ƒ

-33-

The de ve lopm e nt st r uct ur e s t h e m e . This describes t he concret e resources used t o design, im plem ent , and deliver t he syst em . The focus here is on describing t he st ruct ures t o be built and t he st ruct ures required along t he design and developm ent pat h. These include such t hings as layers of t he archit ect ure, com ponent st ereot ypes wit h t heir m odels and t heir diagram s, and ot her art ifact s used t o const ruct and deploy syst em s. The ow nership of t hese st ruct ures and how t hey are derived are described in t he I T organizat ion and developm ent process, respect ively. The full- coverage t ool suit e layer, present ed in t his chapt er, out lines how t hese st ruct ures are m anipulat ed and m anaged wit h t he help of specific t ools as part of t he process. The de ve lopm e nt pr oce ss t he m e . This describes t he specific developm ent t asks. These t asks focus on t he creat ion and evolut ion of t he developm ent art ifact s and are specifically support ed by t he t ools and organizat ion of t he st yle. I t s process should at least cover t he ent ire crit ical developm ent pat h, which m ust be defined by t he st yle, including t he repeat cycles necessary t o address t he change and evolut ion of t he syst em properly. However, defining t he process is not enough; it m ust be coordinat ed properly by an I T organizat ion. The I T- or ga niza t ion st r uct ur e t h e m e . This defines how responsibilit ies, roles, and persons are best coordinat ed t o sim plify and support t he specific developm ent process. Oft en, m et hodologies neglect t he int im at e relat ionship bet ween t he process and organizat ion, assum ing t hat t he process is com plet e. However, no m at t er how com plet e and well- t hought out t he process is, t here is no way t o cover

Convergent Architecture

Chapter 1: IT-Architectural Styel

everyt hing t hat can possibly occur during a developm ent effort . An organizat ion m ust be prepared t o handle everyt hing t hat happens in bet ween and around well- defined t asks, bot h t he everyday t hings and t he surprises. I n addit ion, not everyt hing can or should be defined as a specific t ask. For exam ple, at t em pt ing t o define t he act ivit ies of an I T archit ect as a series of t asks would be fruit less. The t asks are t oo com plex and int ert wined t o be able t o be described in an appropriat e w ay. On t he ot her hand, est ablishing an archit ect ure organizat ion wit h specific responsibilit ies and t ools is ext rem ely useful. Thus, t he I Torganizat ion st ruct ure bot h com plem ent s and support s t he developm ent process. How each of t hese t hem es is present ed is left up t o t he I T- archit ect ural st yle it self. I n any case, t his ent ire developm ent m odel will evolve wit h t im e, j ust as any ot her layer in t he st yle. Things will be added, rem oved, m odified, and refined in t he spirit of an evolut ionary approach.

Th e Fu ll- Cove r a ge Tool Su it e Based on t he specific requirem ent s set fort h by t he preceding feat ures of t he I Tarchit ect ural st yle, t he t hird feat ure of a st yle defines effect ive t ools t o support archit ect ure- driven developm ent . Due t o t he coverage and specificit y of t he developm ent m odel, t ools can be designed, int egrat ed, or im plem ent ed t o act ively assist st yle- conform ing developm ent . They can be t uned specifically t o int elligent ly support developm ent according t o t he developm ent m odel. Wit hout t he previous definit ion of t he feat ures of t he st yle, a com parable range of coverage, int elligent support , and t uning would be im possible. How else is t he t ool developer t o know, specifically, what t he developer requires?

Since specific requirem ent s for t ools are set in t he m odels of t he I T- archit ect ural st yle, expert s can be used t o develop and t une t he t ools in one place t o support all proj ect s using t he st yle. This m eans t hat t he t im e, cost s, and risks associat ed wit h t ool developm ent are reduced. Moreover, t he t ools are m ore effect ive. A proj ect st art ing w it h t he t ools can get st art ed fast er, at lower risk, wit h fewer persons and deliver bet t er result s. This sounds like a m arket ing ploy. However, it is sim ply t he result of sit t ing down and t hinking about a shared I T- archit ect ural st yle, including it s t ool suit e, before proj ect s are st art ed. The sit uat ion is com parable in m any aspect s wit h t he use of specialized CAD t ools by m anufact uring indust ries. First , t he designers of t he t ool sit down and t hink about t he specific requirem ent s for t heir t ool in a given indust ry cont ext —not in all indust ry cont ext s. The specific CAD t ool t hen can be applied t o im prove efficiency in m any developm ent proj ect s wit hin t he part icular indust ry. I t is used t o design various m odels and t o support product ion, for exam ple, in t he special cont ext of helicopt ers. Sim ilarly, in t he I T indust ry, we use t he archit ect ural t ool suit e t o produce various m odels and t o support product ion in t he special cont ext of a part icular I T- archit ect ural st yle. The I T- archit ect ural st yle im proves t he effect iveness of t he developm ent environm ent by raising it s level of coverage and precision. The specific inform at ion regarding procedures and st ruct ures along t he ent ire developm ent life cycle perm it s t ools t o be developed t hat m ore specifically reflect t he developer's int ent and needs t han can generalized t ools. The level of assist ance and int elligence of each t ool can be increased. For exam ple, a design m odel can be checked for it s

-34-

Convergent Architecture

Chapter 1: IT-Architectural Styel

proper use of st ruct ural feat ures such as pat t erns because t he st yle defines which pat t erns are applicable. The t ool also can act ively clean and im prove t he m odel. I t becom es a developm ent environm ent in which t he designer can add creat ive value rapidly inst ead of being confront ed cont inually wit h t he problem s of t ool int egrat ion and t he poor perform ance of lowest - denom inat or t ool support .

Th e For m a l Te ch n ology Pr oj e ct ion s As point ed out earlier, t ools can be defined t o support m any m ore developm ent t asks in t he cont ext of an I T- archit ect ural st yle t han w ould be possible wit hout a well- defined st yle. Above all, significant new levels of aut om at ion are possible. Today t he accept ed level of aut om at ic const ruct ion is t he com piler. The com piler t ranslat es source code, such as Java or C+ + , int o execut able byt e code or m achine code. The com piler is a code generat or t hat every developer t akes for grant ed in everyday pract ice. Nobody in his or her right m ind would consider producing m achine code by hand. I nst ead, we program in a higher- level language, which is read by a generat or—t he com piler in t his case. This generat or gives us im m ediat e feedback regarding m any errors while allow ing us t o describe a program precisely at t he level of source code. At t his level, t he source code can be seen as t he m odel, which is int erpret ed by t he com piler. The com piler produces a predict able result in every sit uat ion; it is a form al m apping of source code t o m achine code. Suppose now t hat we m ove our source code t o a com plet ely different t ype of hardware, where t he m achine code is different . Today's com pilers t ake care of such t asks. The com piler on t he new syst em generat es t he proper m achine code w it h form ally predict able behavior. I n ot her w ords, t he com piler, as a generat or, form ally proj ect s t he source- code m odel ont o any num ber of different t arget plat form s. We call t his a form al t echnology proj ect ion. I n a m odern I T- archit ect ural st yle, t he level and effect iveness of such form al t echnology proj ect ion are raised several levels above t he com piler. This next level of t echnology proj ect ion is sim ply a nat ural evolut ion of t he scenario present ed in t he preceding paragraph. I n t his scenario, t he value of source- code- driven proj ect ion is very clear. There is no reason why t his process cannot evolve t o t he level of m odel- driven proj ect ions t o ent ire server plat form s. Exam ples of such plat form s would be m iddleware infrast ruct ures, applicat ion server infrast ruct ures, or even m ainfram e infrast ruct ures. Model- driven t echnology proj ect ion sim ply m eans t hat we t ranslat e high- level m odels t o ent ire I T infrast ruct ures inst ead of j ust t ranslat ing source code t o m achine code. Such higher- level generat ors cover m uch m ore ground t han t he source- code- based com pilers while delivering com parable dependabilit y and qualit y. There is no downside t o t his scenario if it is posit ioned properly as part of an overall I T- archit ect ural st yle. However, if not used in t he cont ext of an I T- archit ect ural st yle, such generat ors j ust becom e a fast er way t o produce ad hoc archit ect ure. Code generat ion from m odels is st art ing t o cat ch on in t he I T m arket place. However, generat ing code from j ust any m odel is t he best way t o produce a soft ware landscape t hat pract ically nobody underst ands, nobody can reuse, and nobody can m aint ain. The m odels and t ools of an I T- archit ect ural st yle provide t he only sound basis for high ret urns from t he t echnology proj ect ion of m odels t o diverse im plem ent at ion t echnologies—not j ust t o source code. Wit hin t he cont ext of t he I T- archit ect ural st yle, t he developm ent m odel provides guidelines as t o what m odels and t heir result ing syst em s should look like. The archit ect ural t ool suit e t hen support s t hese design guidelines t o help designers produce consist ent m odels

-35-

Convergent Architecture

Chapter 1: IT-Architectural Styel

according t o t he organizat ion's I T- archit ect ural st yle. The t ools can act ively check m odels before generat ion, based on t he guidelines for m odeling and t echnology proj ect ion. This level of m odel checking is analogous t o t he im m ediat e feedback provided by a com piler, only at a higher level. This is a best - of- bot h- w orlds sit uat ion. The effect iveness of t he generat or is increased because a m odel cont ains m ore inform at ion about t he ent ire infrast ruct ure t han j ust source code. The qualit y of t he m odel is increased, which m eans t hat it is of m ore value as docum ent at ion and as a basis for design reuse. Last ly, t he developer is m ore effect ive because m uch of t he developm ent work can now be com plet ed, and verified, in a high- level m odel. Technology proj ect ions are, as required by an I T- archit ect ural st yle, as com plet e as possible. All t he inform at ion a m odel can provide should be used t o generat e as m uch of t he t echnology infrast ruct ure as possible—reducing program m ing, configurat ion, and build environm ent developm ent t o a m inim um . This is im port ant because com plet ing t hese t asks by hand adds virt ually no value t o t he inform at ion already available in t he m odel. To t he cont rary, t hese are t he areas where, current ly, m uch of t he risk is incurred in proj ect s. I n cont em porary developm ent organizat ions, m ost of t he t im e is spent coding by hand from poorly elaborat ed m odels. This is also where t he m ost expensive m ist akes are m ade—from bot h t he short - and long- t erm perspect ives. By raising t he coverage and level of aut om at ic t echnology proj ect ion, an I T- archit ect ural st yle im m ediat ely increases qualit y and speed in individual proj ect s while at t he sam e t im e at t aining t he long- t erm crossorganizat ion benefit s of I T archit ect ure. Technology proj ect ions should be as form al as possible while not losing sight of usabilit y; t here is always a pragm at ic t radeoff bet ween usabilit y and form al specificat ion t hat m ust be m ade in each I T- archit ect ural st yle. Alt hough com piled program m ing languages are form al descript ions, m ost every level of abst ract ion above t hem is, at best , sem iform al t oday. [ 7] For exam ple, t he widely accept ed m odeling language UML is sem iform al and will rem ain so for som e t im e. This does not m ean t hat UML is not useful—t o t he cont rary. However, t he long search for t he best possible m ix of form al rigor and ease of use cont inues. This m ix is not localized t o one part icular area of design. I t st ret ches across t he whole developm ent process, from business m odel represent at ions t o t echnical m odel represent at ions t o t echnology proj ect ions of t he m odels. This is why t he ent ire process is covered by t he I T- archit ect ural st yle. I t is a prerequisit e plat form for im proving t he int eract ion bet ween design m odels and t echnology proj ect ion, an area where m uch progress will be m ade in years t o com e. The t echnology proj ect ion m ust separat e t wo life cycles t hat do not belong t oget her: t he life cycle of t he business- relevant archit ect ure m odels from t he com plet ely different life cycle of im plem ent at ion t echnologies. I m plem ent at ion t echnologies change at a breakneck pace. The m arket and vendors dict at e t hese changes, not t he syst em archit ect . I nst ead of evolving, im plem ent at ion t echnologies oft en are sim ply replaced by alt ernat ive t echnologies. This pace of change is one of t he m ost significant problem s in t oday's I T syst em s. Cont em porary design m odels, if t hey exist at all, are t ailored t o t he underlying t echnology. They are m ore or less im ages of t he im plem ent at ion t echnology. I n t hese cases, when t he im plem ent at ion t echnology changes or is replaced, t he design m odel breaks wit h it . This is a big problem because it m eans t hat t he life cycle of our business is disrupt ed by t he life cycle of ext ernal soft ware and t he

-36-

Convergent Architecture

Chapter 1: IT-Architectural Styel

decisions of soft ware vendors. For t his reason, m ost design m odels seldom live longer t han one syst em generat ion. Unfort unat ely so, because t his m eans t hat t he m odel never get s past t he level of a prot ot ype. Lit t le or no increm ent al im provem ent t akes place. The bot t om line is t hat t he business and design m odels m ust live and evolve over t im e as independent as possible of t echnology life cycles. This is what t he t echnology proj ect ion guarant ees. I t reads a design m odel and t ranslat es it t o t he current best im plem ent at ion t echnology. I t is a useful level of abst ract ion t hat cleanly separat es t he concerns of business and syst em m odeling from t heir m apping t o highly volat ile, rapidly changing t echnologies. This enables t he business and design m odels t o im prove over t im e in a nat ural, evolut ionary m anner. The benefit s of t echnology proj ect ion st em from a forw ard, archit ect ure- driven approach. [ 8] As point ed out in t he preceding paragraph, t he clean separat ion of design from variant s and t he volat ilit y of t echnology plat form s can, wit h rare except ions, only be achieved via forward t echnology proj ect ion. Norm ally, at t em pt ing t o derive a m odel from t he t echnology plat form recouples t he m odel wit h t he life cycle and volat ilit y of t he plat form or wit h t he requirem ent s of one part icular plat form . A good analogy t o illust rat e t his point is t he t ranslat ion of hum an languages. Writ t en language in t he form of t ext is analogous t o design m odels in t hat t he t ext is a writ t en, st ruct ured expression of ideas, in m any ways sim ilar t o a m odeling language. Now, suppose t hat we have an English t ext . We want t o effect ively im prove and ext end t his t ext over t im e, analogous t o t he way we need t o refine and ext end a business m odel at our own pace, wit h m any it erat ions. Forward- t ranslat ing t he English t ext t o several different languages is relat ively sim ple. This is com parable wit h forward- t ranslat ing a design m odel t o an I T infrast ruct ure. West ern languages are t he sim plest t arget s because t hey have Lat in alphabet s and sim ilar gram m ar, but I can t ranslat e m y English sent ence t o m ore exot ic Asian and Arabic languages as well. I can repeat t his forwardt ranslat ion as oft en as I like, for every edit ion of m y t ext and t o any languages I want . Each new t ranslat ion im proves wit h t he qualit y of m y t ext . However, t he reverse direct ion poses a m aj or problem . I f I t ry t o recreat e m y t ext from any of t hese t ranslat ions, it will be different . Not only t he st ruct ure but oft en t he precise m eaning of m y t ext will have changed and usually will differ from t he ideas I originally want ed t o convey. I n addit ion, t he recreat ed t ext is different for each language, even for t he sim ilar West ern languages. I s t his t he sam e t ext ? Are any of t hem bet t er t han m y original? Can I ever get m y original, which I underst and best , back? The obvious answ er is no. From t his scenario it is clear t hat t he reverse derivat ion of nont rivial m odels from im plem ent at ion t echnology, for what ever reason, does not m eet our requirem ent . I n ot her words, forward t echnology proj ect ion has every advant age, but reversing t he process causes t he exact problem t hat we are t rying t o avoid. A forward t echnology proj ect ion t o, for exam ple, various applicat ion servers on various operat ing syst em s or even t o m ainfram e infrast ruct ures is quit e useful, even t hough each of t hese requires significant ly different art ifact s and code st ruct ures t o represent t he sam e m odel. I n sum m ary, a forward t echnology proj ect ion is t he only long- t erm m eans t o benefit from t he posit ive aspect s of new t echnology while prot ect ing t he business from it s negat ive aspect s.

-37-

Convergent Architecture

Chapter 1: IT-Architectural Styel

Aspe ct s Affe ct ing An y I T- Ar chit e ct ur a l St yle A few general aspect s or principles are of part icular im port ance when creat ing an I T- archit ect ural st yle. These aspect s affect t he refinem ent and use of each of t he t op- level feat ures list ed previously. I f t hey are not t aken int o account when defining t he st yle, t hen it will m ost cert ainly be m ore difficult t o apply t han it should be. Since t his is not an int roduct ion t o I T design, I will not cover adj ect ives describing self- evident feat ures of any good design, such as pragm at ic, underst andable, useful, adequat e, and so on. This does not m ean t hat t hese aspect s should be ignored. I t m eans t hat t hey are so basic t o overall design t hat I consider t hem t o be self- evident and om nipresent in every design decision of a skilled designer.

Spe cificit y Designers are paid t o build syst em s and prefer t o spend t heir t im e com plet ing t his t ask, not on preparat ory work such as t he invent ion or definit ion of an I T organizat ion, t he refinem ent of t he developm ent process, or t ool int egrat ion—t o nam e j ust a few. Sadly, m ost cont em porary m et hodologies are collect ions of generalized best pract ices t hat are t oo nonspecific t o be applied direct ly in a proj ect . They require considerable t ailoring, refinem ent , and experim ent at ion before t hey can be used in a part icular inst ance. I n addit ion, t hey oft en cont ain m any overlapping alt ernat ives, obscuring any clear guidelines for t heir specific use t o get t he j ob done. The closer we can com e t o a cookbook, t he bet t er, as long as our recipes are st ill valid for t he sit uat ions at hand. I n ot her words, t he m ore specific an archit ect ural st yle is, t he bet t er. Of course, t he degree of specificit y in any given area depends on t he am ount of flexibilit y required. This is where t he archit ect ural st yle can add significant value. The designers of t he archit ect ure preselect t he m ost effect ive set of t radeoffs t o best m eet t he goals of t he archit ect ure. The specific m ixt ure of t radeoffs is precisely what different iat es one I T- archit ect ural st yle from anot her. Referring once m ore t o t he analogy from t he aut om obile indust ry, it is obvious t hat a roadst er- st yle aut om obile addresses sim ply a different set of design priorit ies or t radeoffs t han a pickup- t ruck- st yle aut om obile.

For anot her exam ple nearer t o hom e, t he developers of t he Convergent Archit ect ure have t aken volum es of generalized m et hodologies such as t he Obj ect Orient ed Process Environm ent and Not at ion ( OPEN 1997) and t he Rat ional Unified Process ( RUP 1998) and filt ered out t he best set of specific pract ices for it s st yle of design. I t t ight ly int egrat es t hese specific pract ices and defines exact ly how t hey fit t oget her. The designer no longer has t o deal wit h a sack full of alt ernat ives and opt ions. I nst ead, m ore specific roles, procedures, and t echniques are applied using t ools designed t o support t hese specific feat ures. The definit ion of specific t echniques and procedures is clearly a prerequisit e t o defining high- product ivit y t ools t o support specific t echniques. Specific guidelines reduce am biguit y—a m aj or source of error, risk, and cost . Wit hout specific guidelines, it becom es next t o im possible t o build t hings t o be com pat ible. Consider, for exam ple, a scenario where several groups are given t he

-38-

Convergent Architecture

Chapter 1: IT-Architectural Styel

t ask of building som et hing as sim ple as a chair. I f inst ruct ions are not given as t o t he height , size, and basic st ruct ure of t he chair, every group will produce som et hing different . However, since everyone know s from experience what a chair looks like, all t he chairs probably will work. Now ext rapolat e t his sit uat ion t o som et hing as com plex as an aut om obile and as invisible as an I T syst em . I t is clear t hat every bit of specific inform at ion, t oget her wit h t he qualit y of t he t ools, will help avoid frust rat ing problem s, part icularly w hen diverse groups build pieces of syst em s t hat should work t oget her. Specificit y is not lim it ed t o low- level det ail. I t pays off at every level of abst ract ion. A high level of clarit y and effect ive com m unicat ion can begin j ust by nam ing t he part icular I T- archit ect ural st yle. Com pare t his, for exam ple, wit h t he specificat ion of cult ural cooking preferences used by m ost of us quit e frequent ly. A whole lot is com m unicat ed sim ply by specifying a French rest aurant , in cont rast t o a Chinese or fast - food rest aurant . Once t he st yle of cooking has been nam ed, m any det ails are aut om at ically clear t o all part ies involved. Specificit y, when done properly, is not synonym ous wit h aggravat ing const raint s. To t he cont rary, it m eans highlight ing t he best pat h t o success in a com plex const ellat ion of alt ernat ives. This is not som et hing t hat happens as a by- product of day- t o- day developm ent proj ect s. I t is only achievable t hrough a concert ed effort by people who have enough experience and an am ple port ion of const ruct ive foresight —t he owner ( or owners) of t he I T- archit ect ural st yle.

Th e For ce of En t r opy Even in t he field of soft ware design, som e laws of physics or, m ore precisely, laws of t herm odynam ics apply. To m ake progress, any engineer m ust recognize t he fundam ent al laws of physics and act accordingly. Ot herwise, bridges fall and soft ware syst em s fail dram at ically—sooner or lat er. Virt ually all soft ware syst em s t oday suffer t o an unnecessary degree from t he force of ent ropy. [ 9] The larger t he syst em or set of syst em s, t he worse t he problem t ends t o be. An I T- archit ect ural st yle is t he best place t o count er t his t rend. Sim ply put , t he force of ent ropy m eans t hat uniform disorder is t he only t hing t hat happens aut om at ically and by it self. I n ot her w ords, if you want t o creat e a com plet ely ad hoc I T archit ect ure, you do not have t o lift a finger. I t will happen aut om at ically as a result of day- t o- day I T act ivit y. Everybody has seen ent ropy at work. Most of us have worked hard cleaning out t he at t ic or t he garage. Who worked on creat ing t he m ess? Nobody, t he m ess happened by it self. The only w ay t o prevent it is t o work against it up front , by inst alling shelves, for exam ple, or ot herwise invest ing energy t o bet t er organize t he at t ic or garage. I n large soft ware syst em s, t he word archit ect ure is synonym ous wit h w ork invest ed at t he proper level t o organize t he syst em . I T archit ect ure defines t he organizat ion of a syst em . However, m ost I T archit ect ures t oday are done wit hin single proj ect s or sm all groups of proj ect s. This is like let t ing one person define t he order and shelving in one port ion of t he garage and allowing ot hers t o det erm ine it in ot her part s of t he garage wit hout t hinking about t he organizat ion of t he ent ire garage first . I n t his case, t he ent ropy sim ply t akes it s t oll at anot her level, nam ely, in bet ween t he proj ect s and syst em s, w hich is not m uch bet t er t han no archit ect ure at all. This is precisely t he reason m any com panies have st art ed addressing Ent erprise Applicat ion I nt egrat ion ( EAI ) . EAI devot es it self t o t he problem s caused by t he lack of a holist ic, overall archit ect ural st rat egy. Unfort unat ely, EAI usually only deals wit h t he sym pt om s of ent ropy, not t he source. I t only pat ches t he problem s

-39-

Convergent Architecture

Chapter 1: IT-Architectural Styel

caused by ent ropy. I f EAI is not applied in t he cont ext of an overall I T- archit ect ural st rat egy, it it self becom es subj ect t o t he force of ent ropy. This m eans t hat , over t im e, EAI becom es part of t he very problem it is at t em pt ing t o solve. The holist ic approach t aken by an I T- archit ect ural st yle handles t his problem at t he proper level, across any num ber of proj ect s and syst em s com prising an overall I T landscape, t hat is, across t he whole at t ic or garage. I t curbs t he force of ent ropy not only wit hin proj ect s, but also across proj ect s. This sounds like a lot of work, and it is, bot h for t he ow ner of t he I T- archit ect ural st yle and for t he chief archit ect in a large organizat ion. However, t he payoffs m ore t han rem unerat e for t he effort . I n sum m ary, design levels t hat are left t o chance w ill result in ad hoc, creeping ent ropy t hat significant ly increases com plexit y—t he source of m ost I T- relat ed problem s. I n cont rast , explicit ly account ing for t he int rinsic force of ent ropy ( soft ware ent ropy) will be t he single m ost significant cont ribut ion t o overall sim plificat ion an I T- archit ect ural st yle can m ake.

Th e D e sign e r 's Pa r a dox Be aware of what som e see as a paradoxical relat ionship bet ween design flexibilit y and design coverage, known as t he designer's paradox. There is a t endency t o believe t hat t o keep a design and it s result ing syst em flexible and independent of change in a part icular area such as t echnology, t ools, or organizat ional st ruct ures, it is best t o ignore t his part icular area in t he design. I n ot her words, if you leave it out of t he equat ion, t hen you are free t o change it at will. The cont rary is t rue: I f you want t o be flexible and independent of som et hing, it m ust be explicit ly covered in t he design; ot herwise, you risk an im plicit coupling t hat resist s change. For exam ple, I once worked on a large proj ect where t he support of m aj or organizat ional changes was of ut m ost priorit y. When I ent ered t he proj ect , I was confront ed w it h a design t hat showed no t race of an organizat ional unit , alt hough t he current organizat ion clearly had been used t o part it ion t he design. When I inquired how t he t eam int ended t o repart it ion t he syst em t o fit new organizat ional st ruct ures, t he answer was: We left t he organizat ional st ruct ure out of t he design t o rem ain independent of it . The paradox was t hat t his om ission had t he opposit e effect . The current design was com plet ely bound t o t he current organizat ion—it s part it ioning of work, it s access cont rol, it s profit cent ers. There was no clear way t o reconfigure t he syst em t o com pensat e for significant organizat ional changes. To enable such flexibilit y, t he design t eam had t o int roduce t he concept of organizat ional st ruct ure int o t he m odels. The apparent paradox here is t hat we are dependent on our design m odels and t echniques t o at t ain independence in our syst em . Our designs m ust explicit ly focus on t hings t hat we want t o flexibly change. This m eans t hat t o increase business flexibilit y, t he business m ust be visible in t he I T m odel. I f a business process needs t o be changed, t hen it had bet t er be visible in t he design. Ot herwise, t im e and effort will be wast ed as well as risk increased j ust figuring out where t he process is and how it can be changed. By t he sam e t oken, t o achieve independence from t he const raint s of t echnologies, t hese const raint s m ust be dealt wit h explicit ly in t he design st yle and in t he t ools we use. [ 10] There are t wo im port ant m essages here for t he developer of an I T- archit ect ural st yle. First , t he st yle m ust t ry t o cover all areas where independence and flexibilit y are required in t he business of building I T syst em s. Second, t he st yle and it s t ools should avoid const raint s t hat w ould inhibit t hem in t heir capabilit y t o achieve

-40-

Convergent Architecture

Chapter 1: IT-Architectural Styel

flexibilit y t hrough design. To t he cont rary, t he st yle should increase design expressiveness w hile at t he sam e t im e sim plifying t he design and developm ent process as a whole. This principle alone rules out m ost , if not all, fourt h- generat ion language concept s and t ools as candidat es for I T- archit ect ural st yle. Alt hough such t ools m ay sim plify som e part icular sit uat ions, t hey also severely const rain t he designer.

Or ga n ic Or de r Many observat ions of t he Bauhaus school of archit ect ure and m odern archit ect ural icons such as Christ opher Alexander direct ly apply t o t he field of I T archit ect ure. An aspiring I T archit ect can learn a great deal from such observat ions, which are not lim it ed t o t he dom ain of civil archit ect ure.

AM FL Y

Of t hese observat ions, t he principle of organic order as form ulat ed at lengt h by Christ opher Alexander ( Alexander 1975) is part icularly im port ant when developing an I T- archit ect ural st yle. I n short , he st at es t hat " [ A rigid m ast er plan] ... creat es an ent irely new set of problem s, m ore devast at ing in hum an t erm s t han t he chaos it is m eant t o govern." This principle em phasizes t hat propert ies of com plex syst em s cannot be predict ed over long periods of t im e no m at t er how gift ed t he designer. For t his reason, t hese propert ies cannot be det erm ined or governed by a rigid m ast er plan. The principle of organic order also confirm s t hat t he long- t erm success of large syst em designs is as m uch a fact or of t he people involved and t heir m ot ivat ions as of t he t echniques and t echnology used.

TE

This is anot her way of saying t hat wat erfall- like developm ent effort s do not work in t he area of com plex syst em design. Thus, a good I T- archit ect ural st yle w ill consider t he hum an- organizat ional requirem ent s of I T developm ent in addit ion t o t he developm ent st ruct ures and t he developm ent process. I t also will foresee an it erat ive, increm ent al approach and t he dist ribut ion of responsibilit ies required t o achieve healt hy organic order.

Or ga n iza t ion a l Evolu t ion

Large I T proj ect s place significant requirem ent s on bot h t he I T organizat ion and ot her organizat ions of t he business. To achieve posit ive change, t hese organizat ions will have t o adapt . Sadly, t he capabilit y t o adapt also m ust evolve; m ost organizat ions resist change. They t oo can only evolve increm ent ally. Alexander ( 1975) refers t o t his as " piecem eal grow t h." The bot t om line is t hat t he archit ect m ust view business organizat ions as living syst em s, not form ally designed m achines. Thus, a successful I T- archit ect ural st yle will assist t he archit ect in achieving increm ent al evolut ion at t he organizat ional level in addit ion t o t he t echnological level. Correspondingly, Dr. David A. Taylor ( Taylor 1997) observed t hat t he long- t erm goal of any business m ust be t o reduce t he im pedance t o posit ive change. I t m ust st rive t o evolve organizat ions from react ive t o creat ive adapt ivit y: " Move organizat ions from a react ive t o pro- act ive adapt ivit y and t hen from pro- act ive t o creat ive adapt ivit y." How well t his hum an fact or can be support ed act ively by an I T- archit ect ural st yle is quest ionable. However, t he owner of t he st yle cert ainly can recognize t his goal t o ensure t hat it s feat ures and t ools, as well as t he syst em s

-41-

Team-Fly®

Convergent Architecture

Chapter 1: IT-Architectural Styel

produced using t he st yle, do not const it ut e an addit ional barrier t o creat ive adapt ivit y. D e scr ibing t he St yle Using St a n da r ds The holist ic breadt h and specific dept h of an I T- archit ect ural st yle require t he expert int egrat ion of diverse not at ional and descript ion st andards. No one m odeling or not at ional st andard could be expect ed t o effect ively cover t he ent ire developm ent life cycle at so m any levels of abst ract ion. For exam ple, even t he m ost com prehensive st andards for archit ect ural descript ion, such as I EEE 14712000 ( I EEE 2000) , or cont em porary proposals for design reuse, such as Rat ional's Reusable Asset s Specificat ion, are quit e correct ly defined t o cover cert ain design elem ent s at specific levels of abst ract ion, not all elem ent s at all levels. For exam ple, t hese st andards leave t he definit ion of m odeling languages and not at ions such as UML and XML up t o t he respect ive expert s. They com plem ent and add value t o t hese st andards; t hey do not replace and com pet e wit h t hem . The role of t he I T- archit ect ural st yle is com plem ent ary in a sim ilar way. I t uses a com binat ion of archit ect ural descript ion st andards, m odeling st andards, and ot her st andards t o describe t he holist ic and specific aspect s unique t o t he st yle. I t adds value by applying t hese st andards in concert at all levels of t he big pict ure. I t does t his in a part icular fashion t o best m eet specific principles—t he essence of a st yle. The scope of an I T- archit ect ural st yle requires ext ensive know- how t o define an effect ive and synergist ic const ellat ion of st andards. The com plexit y of t his t ask is already visible at t he highest levels of an archit ect ure. The four t op- level feat ures of an I T- archit ect ural st yle t raverse m any design dom ains, each of t hem having it s own best m eans of represent at ion. As you will see in t he Convergent Archit ect ure, represent at ions exist for such diverse aspect s as business design, t he I T organizat ion and process design, large- scale and det ailed com ponent syst em design, t ool and reposit ory design, deploym ent and reuse design, code generat ion, and build environm ent design. According t o t he principle of specificit y, t his does not m ean t o use all st andards and all views available. The developer of an I T- archit ect ural st yle m ust select am ong m any st andards and views t o best represent t he big pict ure at every level. This m eans t hat a specific const ellat ion should be defined t o best support learning and use of t he st yle. Such a const ellat ion, for exam ple, w ould opt im ally represent each design level wit h m inim al overlap and wit hout t ranslat ion loss. Not m any developers possess t he broad experience, nor do t hey have enough t im e, t o properly com plet e t his t ask. Nonet heless, it is a prerequisit e for effect ive developm ent of large syst em s. Thus, once com plet ed by an expert and packaged in t he cont ext of an I T- archit ect ural st yle, all users of t he st yle im m ediat ely reap considerable benefit s. [ 7]

Form al specificat ion languages such as B, Z, and VDM rem ain t he dom ain of m at hem at icians. However, progress is being m ade t o im prove t he form alit y of widespread m odeling t echniques. [ 8]

This is in cont rast t o reverse engineering or im plem ent at ion- driven approaches.

[ 9]

Am erican Herit age Dict ionary ( 1994) : "e n·t r o·py n., pl. en·t ro·pies. 1 . Sym bol S for a closed t herm odynam ic syst em , a quant it at ive m easure of t he am ount of

-42-

Convergent Architecture

Chapter 1: IT-Architectural Styel

t herm al energy not available t o do w ork. 2 . A m easure of t he disorder or random ness in a closed syst em . 3 . A m easure of t he loss of inform at ion in a t ransm it t ed m essage. 4 . A hypot het ical t endency for all m at t er and energy in t he universe t o evolve t oward a st at e of inert uniform it y. 5 . I nevit able and st eady det eriorat ion of a syst em or societ y." [ 10]

This is not t he case in m ost design st yles and t ools t oday, where, in every inst ance, upst ream from t he com piler, design st yles and t ools operat e in t he opt im ist ic bliss of zero const raint s only t o hit t he wall of realit y during syst em im plem ent at ion.

Su m m a r y This first chapt er described t he origin of archit ect ural st yle and it s pot ent ial advant ages when t hese concept s are applied in t he field of I T archit ect ure in t he form of an I T- archit ect ural st yle. I t t hen defined t he design of any I T- archit ect ural st yle. This will enable readers t o bet ter underst and t he fundam ent al concept s behind t he Convergent Archit ect ure, a specific I T- archit ect ural st yle present ed in t he rem ainder of t his book. I n addit ion, t he definit ion in t his chapt er will help readers descr ibe, enhance, or even creat e t heir own I T- archit ect ural st yle. A hist orical perspect ive com pared various form s of archit ect ural st yle as found in civil archit ect ure and m any m at ure indust ries. Exam ples showed t he rat ionale for archit ect ural st yle, and analogies were used t o convey it s pot ent ial benefit s in t he I T indust ry. Scenarios from t oday's m ost significant problem s in ent erprise I T syst em s and soft ware design were used t o show how an I T- archit ect ural st yle can provide perm anent solut ions. The scenarios explain w hy m any of t he current - day approaches only doct or up t he m ost visible sym pt om s of a m ore fundam ent al archit ect ural neglect . They dem onst rat e how an I T- archit ect ural st yle goes furt her t o act ually rem edy t he fundam ent al source of t he problem s—t he only long- t erm solut ion. The chapt er reveals I T- archit ect ural st yle as a significant , evolut ionary advance in I T syst em developm ent , not j ust anot her workaround or quick fix. I n t his chapt er, an I T- archit ect ural st yle was defined as consist ing of four m aj or feat ures: ƒ

ƒ

ƒ

ƒ

The archit ect ural m et am odel The full- life- cycle developm ent m odel The full- coverage t ool suit e Form al t echnology proj ect ions

I n addit ion t o j ust ifying and explaining each of t hese four feat ures, t he chapt er also covered several im port ant aspect s t hat should be considered when creat ing any I T- archit ect ural st yle: ƒ

ƒ

-43-

Specificit y The force of ent ropy

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 1: IT-Architectural Styel

The designer's paradox Organic order Organizat ional evolut ion

Now t hat t he advant ages of t he I T- archit ect ural st yle are clear, it is t im e t o show how t hese concept s m anifest t hem selves in a part icular I T- archit ect ural st yle, t he Convergent Archit ect ure. The next six chapt ers of t his book provide a com plet e descript ion of t he Convergent Archit ect ure. Chapt er 8 t hen gives a pragm at ic hands- on exam ple t o get proj ect s off t o a fast st art . I t is im port ant t o not e t hat t he rest of t he book is not j ust an exam ple of I T- archit ect ural st yle; rat her, it is a com plet e st yle t hat is in act ive use t oday in m any proj ect s. Chapt er 2 st art s t he j ourney t hrough t he Convergent Archit ect ure by providing t he t op- level roadm ap. This is t he big pict ure, t he bird's- eye view. I t int roduces t he four feat ures of I Tarchit ect ural st yle as realized in t he Convergent Archit ect ure and explains how t hey com plem ent each ot her. The subsequent chapt ers provide det ail on each of t he feat ures and t heir relat ionships. This roadm ap approach should help designers and proj ect m anagers orient t hem selves at any t im e wit hin t he big pict ure while exploring t he det ails of t he Convergent Archit ect ure.

-44-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Ch a pt e r 2 : Th e Con ve r ge n t Ar ch it e ct u r e Roa dm a p—D e fin in g a n d m a na gin g t h e big pict u r e Ove r vie w A roadm ap is key t o com m unicat ing inform at ion t echnology ( I T) archit ect ure effect ively. The first t hing t hat an experienced planner does in any field is t o orient his or her t eam according t o a com m on schem e or roadm ap. Whet her it is an expedit ion, a m ilit ary event , a const ruct ion plan, or an I T st rat egy, t he roadm ap helps visualize and coordinat e com m on goals and, m ore im port ant , indicat es t he best pat h t o t ake. I t is t he single m ost im port ant form of inform at ion m anagem ent . The larger and m ore com plex t he endeavor, t he m ore im port ant it is t o st art wit h a roadm ap. Even sm all I T proj ect s are com plex enough t o require a roadm ap. A m ap is essent ial t o any I T organizat ion t hat m ust coordinat e persons, proj ect s, and ever- changing t echnology effect ively over large periods of t im e. I n fact , m ost I T organizat ions will require several levels and t ypes of roadm aps t o guide t hem selves properly along t he precarious j ourney t o effect ive syst em s. First , a high- level roadm ap is required t o show t he pat h bet ween m aj or m ilest ones of t he j ourney. This level corresponds, for exam ple, t o a highway m ap bet ween Paris and Berlin. Once t he organizat ion is m oving in t he proper general direct ion, m ore det ailed m aps can be used. However, if t he general direct ion is w rong, det ailed m aps will not help m uch. Buying a det ailed m ap of Rom e will not help m uch if we are on our way from Paris t o Berlin. I n other words, t he m aps do not j ust help us find t he best rout e som ewhere, t hey also help us figure out where we are at any given t im e, where we have com e from , and how w e get back hom e. Above all, t hey help us explain t o ot hers w here we are, how t o find us, and even bet t er, how t o get t here alone, wit hout requiring an experienced guide at every t urn in t he road. There w ill never be enough experienced guides—experienced I T archit ect s— t o go around. Nobody would expect an aut om obile driver t o know a rout e aut om at ically wit hout having looked at a m ap. By t he sam e t oken, it is obvious t hat not every driver can have an experienced t axi dispat cher in t he passenger seat . However, t his does not seem t o be so obvious in t he I T indust ry. Many organizat ions do expect each and every one of t heir developers t o som ehow know t he rout e and, alt hough t hey oft en have never m et each ot her, t o even agree on t he dest inat ion and a com m on rout e. These are clearly unreasonable expect at ions t hat inevit ably lead t o m aj or problem s. To be successful, organizat ions m ust get accust om ed t o using t he dest inat ions and roadm aps for syst em design published by I T archit ect s. This chapt er present s t he roadm ap of t he Convergent Archit ect ure. I t is hard t o underst and how m odern organizat ions even m anage t o get along wit hout an easily underst andable I T roadm ap. Act ually, t hey usually have no I T roadm ap at all. As a result , m ost I T organizat ions are j ust barely surviving, driven from one problem t o t he next , always t eet ering on t he edge of a breakdown. They spend so m uch t im e finding det ours and correct ing dead ends t hat t heir backlog of unfulfilled requirem ent s is burst ing at t he seam s. How do t hese I T organizat ions know where t hey are going? The honest answer is t hat t hey usually do not really know, not past t he next generat ion of syst em s anyway. They cannot know where t hey are going because t hey have never set a long- t erm dest inat ion. I t is as if

-45-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

everyone were under t he im pression t hat , one day soon, we will not need inform at ion m anagem ent and I T any m ore, so why should we bot her t o t hink about where w e are going in t he next decades? Why look t o t he horizon when nobody is int erest ed in t he direct ion anyway? I n light of t his sit uat ion, it is easy t o underst and why cont em porary I T organizat ions are experiencing considerable difficult y. The perpet ual zigzagging has got t en alm ost everybody confused, from t he t op m anagem ent t o t he end cust om ers.

The cost of t his zigzagging is exorbit ant ly high. The cash consum ed by recent I T st art ups alone is dizzying evidence of t his cost , which is m agnit udes higher in large organizat ions. Do t hese I T organizat ions know where t hey are now? No, t hey cannot know where t hey are because t hey do not have a roadm ap for t heir I T archit ect ure. I f you don't care where you end up, t hen you don't need a roadm ap. However, if you want t o produce increasingly effect ive syst em s over t im e, and if you ever want t o reach t he long- t erm advant ages of I T archit ect ure, t hen a roadm ap is t he only way t o get t here. The roadm ap t o t he I T- archit ect ural st yle is also a decisive fact or in t he qualit y of inform at ion and knowledge m anagem ent in any organizat ion. Cont rary t o what som e m odern m arket ing cam paigns w ould have us believe, knowledge m anagem ent is not som et hing t hat part s of I T syst em s do; knowledge m anagem ent is what all I T syst em s do. I t is t he raison- d'êt re of I T syst em s. Every I T syst em , even a com put er gam e, is built specifically t o put order int o dat a, t o organize dat a int o inform at ion, and t o form ulat e and connect inform at ion t o increase hum an knowledge. Essent ially, t he design of every I T syst em is a design for inform at ion and knowledge m anagem ent . There are, of course, good ways and bad ways t o m anage inform at ion: A good design is synonym ous wit h good inform at ion and knowledge m anagem ent . [ 1] I nform at ion m anagem ent goes furt her t han sim ply st ruct uring inform at ion w it hin a syst em . To design syst em s t hat t ruly help hum ans bet t er m anage inform at ion, in cont rast t o j ust dat a, an organizat ion m ust figure out how it want s t o define, st ruct ure, and relat e inform at ion t o m ake it m ore useful. This is one of t he m ost im port ant aspect s of I T archit ect ure: I t forces an organizat ion t o address issues of how inform at ion will be best m anaged and used at all levels. This em phasizes I T- archit ect ural st yle as t he foundat ion for superior inform at ion and knowledge m anagem ent not j ust at t he level of t he individual syst em but for an ent ire organizat ion, well beyond t he t radit ional scope of I T syst em s. Thus t he Convergent Archit ect ure, beginning wit h it s roadm ap, lays t he groundw ork for im proved knowledge m anagem ent by com m unicat ing how t he process of I T developm ent direct ly support s inform at ion design. There is anot her, m ore subt le reason behind t he roadm ap. I t has t o do wit h t he expect at ions placed on consult ant s by cont em porary m anagers. Organizat ions require soft ware t o support com plex, m ission- crit ical t asks. This m eans t hat a consult ant w ho has been engaged t o build a syst em first m ust work w it h t he business t o underst and and clearly st ruct ure, t hat is, m odel, t he m ission- crit ical t asks. He or she m ust const ruct a roadm ap of t he st ruct ures and procedures in t he part icular business dom ain, whet her it is aut om obile product ion, financial t rading, or st at e governm ent , so as t o design and build an effect ive I T syst em . I n ot her words, t he consult ant has been hired t o define and realize a roadm ap for a business. As a prerequisit e, we should expect t he consult ant t o have a roadm ap for his or her ow n business—t he business of I T archit ect ure—t hat clearly st ruct ures t he m ission- crit ical t ask of I T archit ect ure. We cannot reasonably expect som eone

-46-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

t o develop a high- qualit y roadm ap for anot her business dom ain if t hat person does not yet have one in his or her own dom ain. The rem ainder of t his chapt er present s t he t op- level roadm ap of t he Convergent Archit ect ure in t erm s of t he im port ant st ops along t he recom m ended rout e t o building convergent I T syst em s. I t shows t he locat ions and m ilest ones along t he road of I T archit ect ure as well as t heir orient at ion w it h respect t o each ot her. This is t he " big pict ure" of t he Convergent Archit ect ure, which will significant ly sim plify and expedit e t he ent ire I T endeavor, no m at t er how ext ensive t hat endeavor m ay be. I t s prim ary obj ect ive is t o begin sim ple and st ay as sim ple as possible, rut hlessly abrogat ing unnecessary com plexit y at every st ep along t he w ay. Since t he m ilest ones of t he Convergent Archit ect ure are not necessarily everyday landm arks t hat we all know and underst and—like highw ays, m ount ains, and lakes—t he roadm ap also m ust explain it s ow n part icular landm arks and elem ent s of geography—t he highways, m ount ains, and lakes of I T archit ect ure. Thus, along wit h t he roadm ap, t his chapt er also present s t he high- level anat om y of t he Convergent Archit ect ure in t erm s of it s significant part s and t he im port ant funct ion of each part in t he overall organism . This anat om y lesson began in t he preceding chapt er, where t he significant feat ures of any I T- archit ect ural st yle were explained. The four feat ures of an I T- archit ect ural st yle are clearly visible in t he Convergent Archit ect ure. However, t hey now t ake on addit ional charact er, t he charact er of t his part icular st yle. Aft er int roducing t he roadm ap and anat om y here, t he rem aining chapt ers of t his book t ake us on a j ourney t hrough t he Convergent Archit ect ure, according t o t he roadm ap, and present a det ailed m ap at each st op along t he road t o building convergent I T syst em s. [ 1]

I am not alone in t his point of view. See Lewis ( 1999) , for exam ple.

Th e An a t om y of t h e Con ve r ge n t Ar chit e ct u r e Figure 2.1 shows t he com bined elem ent s of st ruct ure, process, and t ools t hat m ake up t he Convergent Archit ect ure. This is bot h it s anat om y and t he t op- level roadm ap. As wit h any roadm ap, t he orient at ion of it s elem ent s is significant . Layers of abst ract ion run from t op t o bot t om and left t o right . I n ot her words, it should first be read from t op t o bot t om and t hen from left t o right . The t op t wo layers represent t he m odels of t he st yle and indicat e t heir long- t erm influence on t he lower layers, which represent t ool and t echnology cat egories. The t im e perspect ive flows from left t o right and shows t he relat ionship bet ween developm ent process flow, t ool m odules, and t echnologies in any given proj ect .

-47-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Figur e 2 .1 : Roadm ap and anat om y of t he Convergent Archit ect ure. The layers of t he Convergent Archit ect ure and t heir correspondence t o t he four feat ures of an I T- archit ect ural st yle are

1. The Conve r ge nt Ar chit e ct ur e m e t a m ode l. This layer fulfills t he role of t he archit ect ural m et am odel, as defined in Chapt er 1. 2. The de ve lopm e nt m ode l. This layer fulfills t he role of t he full- cycle developm ent m odel, as defined in Chapt er 1. 3. The a r chit e ct ur a l I D E a nd it s a ssocia t e d r e usa ble a sse t s. These t wo layers fulfill t he role of t he full- coverage t ool suit e, as defined in Chapt er 1. 4. The t e chnology pr oj e ct ions. This layer fulfills t he role of t he form al t echnology proj ect ions, as defined in Chapt er 1. Each of t hese layers is int roduced in t he following sect ions before being covered in det ail in a subsequent chapt er. The Conve r ge nt Ar ch it e ct ur e M e t a m ode l The Convergent Archit ect ure m et am odel defines t he long- t erm vision and fundam ent al design principles on which we base our design decisions. I n sum m ary, it com prises t he following elem ent s: ƒ

-48-

The t hr e e pilla r s of h olist ic a r chit e ct ur e . The int im at ely relat ed t hem es of proj ect design, business design, and syst em design are addressed t o provide adequat e coverage of t he areas crit ical t o an I T organizat ion and it s m any int errelat ed proj ect s. The proj ect design pillar refers t o how we set up, coordinat e, and run t he I T organizat ion, it s proj ect s as well as it s developm ent workflow. I t set s t he st age for bot h effect ive business and syst em design. The business design pillar refers t o t he t echniques and t ools required t o refine t he business

Convergent Architecture

ƒ

ƒ

ƒ

ƒ

ƒ

-49-

Chapter 2: The Convergent Architecture Roadmap

st rat egy and t o represent it in a form t hat can be underst ood widely and m apped efficient ly t o an I T syst em . The syst em design pillar t hen indicat es how w e get from t he business design t o an I T syst em t hat opt im ally support s t he business. Conve r ge n ce a nd Con ve r ge nt En gine e r ing. Dr. David A. Taylor ( Taylor 1995) form ulat ed convergence in t he cont ext of I T syst em s in his int roduct ion t o Convergent Engineering. Convergent Engineering dem onst rat es how business and I T m odels can be unit ed int o one, sim plifying m odel t o resolve m any of t oday's m ost com plex operat ional and business- I T problem s. I t also recognizes t he concept of int egrat ed m odeling and t he proper use of obj ect - orient ed t echnology as crit ical fact ors for last ing im provem ent . The m a chine shop m e t a ph or . Pict ure a well- run m achine shop or w orkshop set t ing in any m at ure indust ry, and com pare t his pict ure wit h t he set t ings of cont em porary soft ware developm ent . I t is clear t hat m ost , if not all, soft ware set t ings allow significant room for im provem ent . The Convergent Archit ect ure st rives t o achieve t he level of a well- run m achine shop by creat ing a com parable soft ware shop. I n cont rast t o a consult ant arriving at a proj ect wit h som e ideas about how one could possibly begin building a soft ware shop, t he convergent archit ect is bet t er prepared. He or she st art s wit h a working, t ried, and t est ed soft ware shop t hat covers t he whole process from concept ion t o finishing, analogous t o a well- organized m achine shop. Re duce d Abst r a ct ion Se t Com pu t ing ( RASC) . Based on years of em pirical research, I T archit ect s have been able t o ident ify a reduced set of design elem ent s, or design abst ract ions, t o significant ly sim plify m any aspect s of design and t he design process. This im provem ent is analogous t o t he discov ery of Reduced I nst ruct ion Set Com put ing ( RI SC) in com put er hardw are design, which was recognized as a desirable alt ernat ive t o Com plex I nst ruct ion Set Com put ing ( CI SC) in m ost sit uat ions. RASC const it ut es a high- level language and lexicon t hat can be shared by bot h business and I T designers t o achieve convergence in I T syst em s. The Convergent Archit ect ure recognizes six significant RASC abst ract ions, from which it derives it s fam ily of com ponent s, t he convergent com ponent s. Conce pt ua l isom or ph ism . I f a concept can be learned once and applied sim ilarly in m any sit uat ions, t hen we speak of concept ual isom orphism . The concept s of t he Convergent Archit ect ure are t arget ed for use across m any dom ains. They resolve general problem s at a general level inst ead of repeat edly solving t he sam e problem different ly at t he level of specific syst em s. The Convergent Archit ect ure can be used equally and wit h t he sam e ident ifiable concept s across t he diverse organizat ions of a bank, an aut om obile m anufact urer, and a governm ent agency, for exam ple. A high level of concept ual isom orphism increases t he underst anding of m odels, t ools, and syst em s across dom ains, sim plifying com m unicat ion while also reducing learning curves. Widely usable design pat t erns oft en are good exam ples of concept ual isom orphism . Com pone n t m e t a m or ph osis. There are few physical or m at erial const raint s t o developing soft ware syst em s. They are indeed " soft " in

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

t hat we can conceivably m anipulat e and grow our designs any way we w ant . The principle of com ponent m et am orphosis invokes an int ent ional analogy wit h t he m et am orphosis of a but t erfly. I nst ead of developing soft ware syst em s as done t oday, in radical heaves of t ranslat ion and reform ulat ion of inform at ion, t hey can be evolved t hrough st eady st ages of inform at ion enhancem ent and growt h, com parable wit h t he m et am orphosis of a but t erfly. I t required a concert ed effort in t he Convergent Archit ect ure t o creat e st ruct ures, processes, and t ools t o enable com ponent m et am orphosis. A det ailed descript ion of t he Convergent Archit ect ure m et am odel is present ed in Chapt er 3. The D e ve lopm e nt M ode l The Convergent Archit ect ure's developm ent m odel form ulat es t he principles of it s archit ect ural m et am odel in t erm s of specific design st ruct ures, a developm ent organizat ion, and a developm ent process. I t dist inguishes t he following t hree int eract ing m odels: ƒ

ƒ

ƒ

ƒ

Conve r ge n t com pone nt m e t a m ode l. Convergent com ponent s are t he m ost im port ant st ruct ural vehicle for t he principles of t he Convergent Archit ect ure. They realize t hese principles in t erm s of concret e com ponent st ruct ures, behavior, and relat ionships. The m et am odel defines t echnology- nonspecific concept s for organizat ions, process and resource com ponent s, ut ilit y com ponent s, accessor com ponent s ( syst em - int erface accessors, user- int erface accessors) , assem bly com ponent s, and sent inels. I t also organizes t hese com ponent s int o archit ect ural layers, specifies t heir m apping t o t echnology and runt im e syst em s, and defines t heir specific developm ent process and t ool support . The I T- or ga niza t ion m ode l. This m odel defines a t em plat e I T organizat ion in t erm s of t he organizat ional st ruct ure, roles, and responsibilit ies required for effect ive support and m anagem ent of t he ent ire I T life cycle. I t defines t he canonical proj ect organizat ion and proj ect t eam as w ell as organizat ions for I T archit ect ure, developm ent support , soft ware developm ent , and operat ional syst em s. The de ve lopm e nt - pr oce ss m ode l. Based on concept s from several professional fram ew orks for soft ware developm ent , t he Convergent Archit ect ure defines a specifically t ailored approach, or inst ance, according t he Rat ional Unified Process, known as RUP ( Krucht en 1998) , and t he Obj ect - Orient ed Process Environm ent and Not at ion, know n as OPEN ( Graham 1997) . The developm ent - process m odel focuses on highly specific coverage of t he core developm ent workflow as well as on crit ical aspect s of t he support ing workflows according t o t he RUP. A det ailed descript ion of t hese t hree int eract ing m odels is present ed in Chapt ers 4, 5, and 6, respect ively.

To sim plify orient at ion from t his point on, Figure 2.2 paraphrases t he relat ionships bet ween t he t hree m odels out lined in t his sect ion, as well as t heir relat ionship t o

-50-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

AM FL Y

t he rem aining t wo layers, t he archit ect ural I DE and t he t echnology proj ect ions, which are covered in t he next t wo sect ions.

Figur e 2 .2 : The developm ent m odel and t he layers below. The Full- Cove r a ge Tool Suit e ( Ar chit e ct ur a l I D E)

TE

The full- coverage t ool suit e is an int egral part of t he Convergent Archit ect ure. I t is at t he level of a preconfigured " m achine shop" t hat has been designed specifically t o m eet t he requirem ent s of t he archit ect ure. The t ight ly int egrat ed t ools and aut om at ed assist ant s support im m ediat e and effect ive const ruct ion of archit ect ureconform I T syst em s. We call t his com prehensive approach t o high- level archit ect ural t ools an I T- archit ect ural I DE. [ 2] As em phasized in Chapt er 1, t he definit ion of t he I T- archit ect ural I DE m ust be part of t he I T- archit ect ural st yle. Thus, t he Convergent Archit ect ure specifies t he m odules of it s own I T- archit ect ural I DE. However, it does not specify who should provide t he I T- archit ect ural I DE or any one of it s m odules. To provide t he reader wit h pragm at ic, hands- on exam ples, a concret e I T- archit ect ural I DE is used in t his book, t he ArcSt yler ( iO 2001) . This I T- archit ect ural I DE em beds t he well- known m odeling t ool, Rat ional Rose ( Rat ional 2001) , as one of it s cent ral m odules. Alt hough t he ArcSt yler was developed t o support archit ect ure- driven developm ent in general, it provides explicit support for t he Convergent Archit ect ure st yle. A cent ral aspect of t he I T- archit ect ural I DE is it s support for m apping design m odels t o available t echnologies. We call t his m apping t he t echnology proj ect ion, which is covered in it s ow n sect ion in t he following. The Convergent Archit ect ure leverages J2EE/ EJB st andards and J2EE- com pliant applicat ion servers as it s default t echnology proj ect ion. To properly illust rat e t he various levels of design and im plem ent at ion independence provided by t he I T- archit ect ural I DE, t wo different J2EE applicat ion servers w ill be used wit h t he ArcSt yler in several exam ples in t his book. The J2EE/ EJB applicat ion servers used for t he exam ples are t hose from

-51-

Team-Fly®

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Borland ( Borland 2001) and BEA Syst em s ( BEA 2001) . However, ot her J2EE/ EJBcom pliant applicat ion servers easily could have been used in t heir place. I n t he Convergent Archit ect ure, t he I T- archit ect ural I DE is arranged int o five m aj or m odules, as show n in Figure 2.3. These m odules are not j ust t ool descript ions. More im port ant , t hey are used by t he Convergent Archit ect ure t o sim plify underst anding and applicat ion of it s developm ent st yle. Each developm ent t echnique is present ed pragm at ically in t he following in conj unct ion wit h it s specific t ool support :

Figur e 2 .3 : The m odules of t he I T- archit ect ural I DE. ƒ

-52-

Conve r ge n t Busine ss Obj e ct M ode le r ( C- BOM ) . This m odule assist s bot h t he I T designer and t he business- dom ain expert in t heir j oint t ask of requirem ent s analysis and elaborat ion of t he business st ruct ure and dynam ics. I t provides visual m odeling assist ance t o help ident ify and docum ent a convergent syst em using t he RASC com ponent s described previously. I t does t his using t he proven t echniques of responsibilit ydriven design ( RDD) and class responsibilit y cards ( CRC) , as prescribed by convergent engineering ( Taylor 1995) and OPEN ( Graham 1997) . Cross- funct ional t eam s use t his m odule during t he highly collaborat ive t ask of m odeling, docum ent ing, and t est ing t he business st ruct ure and business dynam ics. This t ask also leverages analysis by design ( ABD) and dynam ic walk- t hrough/ run- t hrough t echniques t o verify m odel com plet eness and qualit y, as described by convergent engineering. Run- t hrough result s are recorded bot h as form al st at e t ransit ion t ables ( STTs) and as a m ore int uit ive graphical form . The graphical represent at ion provides visual docum ent at ion, t racking, and playback.

Convergent Architecture

ƒ

ƒ

-53-

Chapter 2: The Convergent Architecture Roadmap

The rules of t he m odeling st yle are used t o aut om at ically verify and report on t he m odel's int egrit y and com plet eness in bot h st ruct ural and dynam ic aspect s at any t im e. These report s, based on verified m odels, serve as design signoff docum ent s. They also include t est cases in t he form of STTs and t he visual scenarios docum ent ing all run- t hrough pat hs t hrough t he convergent business syst em . The result s of t he business m odeling session are st ored in a reposit ory based on t he st andard Unified Modeling Language ( UML) m et am odel and t he eXt ensible Markup Language ( XML) . This reposit ory is used in a federat ed m anner by all ot her m odules of t he I T- archit ect ural I DE t o guarant ee t he t ranslat ion- free, loss- less enrichm ent of design inform at ion according t o t he principle of com ponent m et am orphosis. Conve r ge n t Pa t t e r n Re fine m e nt Assist a nt ( C- RAS) . This m odule picks up t he result s of t he C- BOM and helps a designer graphically evolve t he business m odel int o a m ore det ailed, m ore t echnically precise m odel represent at ion in UML. This t ask proceeds in a st ruct ured m anner according t o t he principle of convergent engineering. This is achieved by using refinem ent pat t erns based on t hose developed by t he OPEN Consort ium ( Henderson- Sellers 1998) , which are em ployed t o guide t he designer and t o check t he int egrit y of t he refinem ent . Wit h t he visual support provided by t his t ool, t he CRC com ponent represent at ions from t he business m odel are m apped t o UML com ponent represent at ions wit hout losing t rack of t heir origin and wit hout losing t he exist ing inform at ion on t he business com ponent s: The inform at ion is enhanced and refined, not t ranslat ed or replaced. I n t he spirit of assist ed m odeling, m uch of t he UML refinem ent is handled aut om at ically by t he t ool it self according t o t he pat t erns and UML m odeling st yle defined by t he Convergent Archit ect ure. For exam ple, t he proj ect ion t o a st andard J2EE/ EJB com ponent m odel st art s here. The UML m odel is elaborat ed aut om at ically int o a J2EE/ EJB- com pliant design using reasonable default s. The designer can influence t hese default s, but t he t ool suggest s a well- form ed st andard st ruct ure for t he designer t o build on or t une in t he subsequent st ages of refinem ent . Once again, all result s are st ored in t he federat ed UML reposit ory. Conve r ge n t UM L Re fine m e nt Assist a nt ( C- REF) . This m odule reads t he result s of t he C- RAS and now present s t he convergent com ponent m odel at t he level of an advanced UML m odeler for furt her enrichm ent and t uning of t he design. This is t he point where syst em int eract ion and access, whet her via I nt ernet [ 3] or ot her channels, and int eract ion w it h ext ernal syst em s, whet her int ernal or via I nt ernet , [ 4] is elaborat ed in det ail using t he st andard UML. This t ool provides several int elligent archit ect ure assist ant s during t his phase t o furt her preserve convergence and m odel int egrit y and t o ensure t echnological feasibilit y of t he design. The first assist ant checks at any t im e whet her t he det ailed m odel is com plet e and well form ed according t o t he UML, J2EE/ EJB, and Java st andards. Anot her assist ant helps t he designer proceed according t o t he specific m odeling st yle of t he archit ect ure by providing specialized wizards, dialogs, views, and diagram s. A t hird assist ant helps generat e UML m odels for default user- access and t est com ponent s ( which we call accessors) , based on t he exist ing businesscom ponent m odel. This allows t he designer t o m odel and reuse com plex I nt ernet access and int eract ion logic in UML. A fourt h assist ant

Convergent Architecture

ƒ

Chapter 2: The Convergent Architecture Roadmap

helps t he user configure a part icular t echnology proj ect ion and it s runt im e environm ent . Based on t his configurat ion, t he assist ant t hen checks t he m odel at any t im e for it s t echnological feasibilit y. This verificat ion st ep is analogous t o a com piler, except it is working at t he level of a UML m odel. Based on t he capabilit ies and const raint s of t he configured t echnology proj ect ion, t he assist ant point s out which aspect s of t he m odel cannot be m apped effect ively t o t he select ed im plem ent at ion t echnology. Wit h t his j ust - in- t im e feedback, t he m odeler can bet t er m aint ain archit ect ural int egrit y and ensure t he qualit y of t he subsequent syst em generat ion. Conve r ge n t Tr a nsla t ive Ge ne r a t or ( C- GEN ) . This m odule reads t he UML m odel in part s or in it s ent iret y from t he C- REF t ool and generat es t he com plet e com ponent infrast ruct ure, including t he environm ent for configurat ion, const ruct ion, and deploym ent of t he convergent syst em . The generat or t ranslat es t he UML m odel t o t he part icular infrast ruct ure w hile preserving convergence. To do t his, it uses t ransform at ion script s, code- generat ion t em plat es ( for exam ple, for Java, HTML, J2EE/ EJB, XML, or a Java- I DE) , t echnology capabilit y t ables ( for exam ple, for a J2EE/ EJB applicat ion server) , and ot her inform at ion. All t ransform at ion inst ruct ions belonging t o a part icular t echnology proj ect ion are encapsulat ed in a so- called generat or cart ridge, which can be inst alled, configured, and used as a unit by t he developer. The generat or cart ridge is referred t o sim ply as a cart ridge when used in t his cont ext . There can be any num ber of cart ridges, one for each part icular infrast ruct ure. The C- GEN is oblivious of t he specific cont ent of t he cart ridge. I n addit ion, com binat ions of cart ridges can be used in concert t o guarant ee proper m odularit y and separat ion of concerns bet ween coexist ing t ypes of infrast ruct ure, as explained wit h t he C- BOB m odule below. The source code and ot her art ifact s generat ed by t he cart ridge are of consist ent , predet erm ined qualit y. The int ernals of t he art ifact s generat ed ( for exam ple, source code, deploym ent configurat ion, build configurat ion) can be m odified at places deem ed appropriat e by t he I T- archit ect ural st yle. The cart ridge uses several t echniques t o enable t he cont rolled m odificat ion of generat ed art ifact s. These t echniques are present ed in det ail in Chapt er 7. However, it is im port ant t o not e here t hat t he Convergent Archit ect ure m andat es clean m odel- based, m odel- driven developm ent . This m eans t hat all art ifact s t hat generat ed from t he UML m odel can only be ext ended or m odified in a cont rolled m anner—as defined by t he archit ect ural st yle. This is an explicit enforcem ent of t he m odel- driven developm ent approach. However, t he rigor of t his enforcem ent can be regulat ed using t he C- GEN- I DE ( see t he following) t o m odify t he rules of t he code generat ion.

Not all aspect s of a syst em can be represent ed reasonably in UML m odels or derived and generat ed from UML m odels. These aspect s m ust be developed at t he source- code level. To do t his, t he I T- archit ect ural I DE leverages one of t he several program m ing I DEs available on t he m arket. The program m ing I DE m ay be used t o refine, com pile, and debug art ifact s generat ed by t he C- GEN m odule. These art ifact s include Java program s, configurat ion files, t he build environm ent , t est infrast ruct ure, and deploym ent inform at ion. During t he generat ion process, t he cart ridge clearly dem arks and annot at es t he areas where addit ions can or should

-54-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

be m ade in t he Java I DE. This helps t he developer m ake rapid addit ions while m aint aining st ruct ural int egrit y and synchronizat ion wit h t he UML m odels. I n addit ion, t he cart ridge generat es t he art ifact s required by t he Java I DE t o load, build, deploy, and t est t he syst em in t he cont ext of a specific runt im e infrast ruct ure. This includes default t est code t o perm it evolut ionary m odificat ion and t est ing of t he syst em . ƒ

ƒ

Conve r ge n t Ge ne r a t or I D E ( C- GEN - I D E) . This I DE is t he visual developm ent environm ent for a generat or cart ridge. The developm ent of a cart ridge can be regarded as m et aprogram m ing because t he script s developed here drive t he t ranslat ive generat ion of m any ot her program s. The C- GEN- I DE is required only when a developer needs t o ext end or adapt a cart ridge. I n t his case, t he cart ridge is developed visually, t est ed, t raced, and debugged in a sim ilar fashion t o wellknown program m ing I DEs for C+ + or Java. The C- GEN- I DE is used, for exam ple, t o m odify t he HTML- and J2EE- generat ion t em plat es in order t o produce a different look and feel in com pliance wit h a part icular Web sit e branding or a corporat e ident it y. Using t he C- GEN- I DE, t he chief archit ect and lead designers of large, m ult it eam I T organizat ions have a t ool t o t ailor and adapt t he I T- archit ect ural st yle in a well- defined place and form . This helps guarant ee a consist ent level of welldocum ent ed qualit y and archit ect ural int egrit y across all proj ect s. Conve r ge n t I m ple m e nt , D e ploy, a n d Te st Envir onm e nt ( C- I X) . The m odels of t he Convergent Archit ect ure require t hat m odel- based developm ent also cover t he areas of user int eract ion and access t o and from ext ernal syst em s. This is achieved in part in t he C- REF m odule, as described earlier, where t he appropriat e m odeling capabilit ies and assist ed m odeling st yle are provided. I n addit ion, t he UML m odels m ust be m appable t o a st able deploym ent infrast ruct ure t o enable consist ent generat ion, deploym ent , and t est ing of high- perform ance im plem ent at ions. This infrast ruct ure is provided by t he accessor cart ridge, which com plem ent s t he m odeling st yle by furnishing a st able, reusable fram ework in addit ion t o it s t echnology proj ect ion. For exam ple, t he accessor cart ridge for J2EE provides a st able deploym ent and t est infrast ruct ure based on st andards such as JSP, servlet s, and Web archives. The fram ework com plem ent s t hese J2EE st andards in areas required t o enable effect ive m odel- based developm ent in UML but not yet st andardized in J2EE. I t also provides a higher level of abst ract ion t hat increases m odel expressiveness while guarant eeing a t ransparent m igrat ion t o relevant st andards should t hey em erge.

A m ore det ailed descript ion of t he I T- archit ect ural I DE is present ed in Chapt er 7. The Te ch nology Pr oj e ct ions ( J2 EE/ EJB) A t echnology proj ect ion in t he Convergent Archit ect ure specifies how convergent com ponent s and ot her m odeled elem ent s are m apped ( proj ect ed) t o st andard com ponent fram eworks and t hen t o various im plem ent at ion t echnologies. By default , t he Convergent Archit ect ure recom m ends and specifically support s t echnology proj ect ions t o infrast ruct ures based on J2EE/ EJB st andards. This book covers t he t echnology proj ect ions t o st andard J2EE/ EJB infrast ruct ures and uses proj ect ions t o exist ing applicat ion servers from BEA Syst em s ( BEA 2001) and Borland ( Borland 2001) applicat ion servers in it s exam ples. [ 5] However, several

-55-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

ot her t echnology proj ect ions t o non- J2EE t echnologies have been developed already for t he Convergent Archit ect ure. These include proj ect ions t o CORBA ( Visibroker, BEA WLE) , OODB Syst em s ( Versant enJin) , and pure- Java RMI fram eworks. There are t wo aspect s t o a t echnology proj ect ion:

1. Things t hat can be generat ed aut om at ically, effect ively, and wit h reasonable effort 2. Things t hat cannot be generat ed aut om at ically Bot h of t hese m ust be addressed t o m aint ain archit ect ural int egrit y because t oget her t hey define t he t angible result s of t he archit ect ure. The boundary bet ween w hat can and cannot be generat ed reasonably oft en is fuzzy and usually changes wit h t im e. However, bot h aspect s invariably exist in real- world proj ect s. There w ill never be a way t o aut om at e everyt hing because once we have aut om at ed one t hing, we at t ack t he next challenge, which w e usually cannot aut om at e im m ediat ely. I n ot her words, our insat iable appet it e for progress always keeps us out in front of t he m oving aut om at ion boundary. I n addit ion, som e t hings are not wort h aut om at ing at all, nam ely, unique, nonrepet it ive inst ances. For exam ple, a com plex adapt er t o a legacy syst em invariably m ust be writ t en or t uned by hand using all kinds of propriet ary t echnology. However, t he com ponent t hat cleanly encapsulat es t his adapt er from t he perspect ive of t he archit ect ure m ay be generat ed aut om at ically from a UML m odel. Since t he adapt er is com plet ely unique, it is not wort h developing an aut om at ed t echnology proj ect ion for t he special case.

I n t he Convergent Archit ect ure, t he design int egrit y of t he aut om at ically generat ed aspect s is handled by t he generat or cart ridge, which not only aut om at es t he m anagem ent of t echnology, but also docum ent s how t he t echnology is m anaged. The concept s and workings of a generat or cart ridge were out lined in t he preceding sect ion and are det ailed in Chapt ers 4, 7, and t he bonus chapt er on t he Web sit e. The int egrit y of part s t hat cannot be generat ed aut om at ically is addressed by socalled sent inels. A sent inel com plem ent s t he generat or cart ridges by specifying t he proper use of t he t echnologies t hat are not m anaged explicit ly by aut om at ic generat ion. A sent inel is a docum ent or som e ot her st ruct ure in which t he archit ect designat es how a part icular t echnology is t o be used from t he perspect ive of t he archit ect ural st yle. This is t he only way t o keep an I T landscape clean as a whole. I t is one of t he best invest m ent s against soft ware ent ropy. Sent inel docum ent s, or sent inels, are also im port ant because t hey t ell developers what is in bounds and what is out of bounds from t he perspect ive of t he archit ect ure. They draw a boundary t o m ore clearly delim it what is good and bad in t erm s of archit ect ural int egrit y. For exam ple, large organizat ions usually want t o int egrat e m any packaged syst em s, such as Lot us Not es or Microsoft Exchange, int o t he overall syst em landscape. I n such a sit uat ion, t he archit ect [ 6] w rit es a sent inel defining which int erfaces and feat ures of Lot us Not es can be used in t he com pany's soft w are, as well as any const raint s pert aining t o t heir use. I f t his is not done, t hen part s of

-56-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Lot us Not es' infrast ruct ure will creep unnot iced and unhindered int o t he I T landscape, causing a com plex, uncont rolled int erm ingling of t he organizat ion's syst em s w it h t he ext ernal t echnology and design philosophy of Lot us Not es. Once t his happens, t he organizat ion's I T- archit ect ural st yle has been pollut ed: Creeping ent ropy has begun t o t ake it s t oll. I call t his process creeping dilut ion ( or pollut ion) of t he archit ect ure. Once it st art s, t he com pany should not w onder why bot h I T com plexit y and t he num ber of unpleasant surprises st eadily increase. I f a sent inel were in place, anybody could see where and how t he Lot us Not es' infrast ruct ure is used or should be used in a cont rolled, organized m anner from t he perspect ive of t he archit ect ure. Met aphorically speaking, t he sent inel heads soft ware ent ropy off at t he drawbridge. I t is an im port ant m easure t aken by t he archit ect ure t o guard it self from int ruders. More det ails on sent inels will be provided in lat er chapt ers. The t echnology proj ect ion ( Chapt er 4 and t he bonus chapt er on t he Web sit e) sim plifies risk m it igat ion by defining t hree dist inct cat egories of sent inel. They are used t o com m unicat e and m anage t he long- t erm risks of change and coupling relat ed t o t he use of ext ernally developed t echnology. Ext ernally developed t echnology refers t o any design or im plem ent at ion t hat has occurred out side t he cont ext of t he I T- archit ect ural st yle. The problem wit h ext ernally developed t echnology is t hat it s design, it s im plem ent at ion, and it s life cycle are not cont rolled by t he archit ect ure, but it st ill m ust be m anaged effect ively by t he archit ect ure. Defining t he high- value, low- risk use of ext ernally developed t echnology wit hin an organizat ion is key t o achieving overall high- ret urns from t echnology. The following t hree cat egories of sent inels classify ext ernal t echnologies in t erm s of t heir pot ent ial for risk from t he perspect ive of t he archit ect ure: ƒ

ƒ

ƒ

-57-

Ubiquit ous t e chnologie s. These are t he t echnologies t hat are used w idely t o im plem ent and int erface t he convergent com ponent s ( see Chapt er 4) across an ent ire I T landscape. These t echnologies include t he corporat e I T infrast ruct ure down t o it s lowest level. Exam ples here begin wit h t he net working infrast ruct ure, com put er operat ing syst em s t hat underlie all inst alled soft ware, but also include ot her ubiquit ous t echnologies, such as t he Java Developm ent Kit , XML exchange form at s, and t he m yriad t echnologies bundled wit h or encapsulat ed by J2EE/ EJB applicat ion servers ( which includes dat abases) . These sent inels ensure t hat t he aut om at ed aspect s of t he archit ect ural st yle also define how t hey use and rem ain in sync w it h t he rest of t he I T environm ent . CC- e nca psula t e d t e chnologie s. These are t echnologies t hat fall out side t he ubiquit ous t echnologies cat egory. As such, t hey will always be cleanly encapsulat ed wit hin convergent com ponent s. Such t echnologies are, for exam ple, special com m unicat ion m iddleware t o access packaged applicat ions and legacy syst em s, special B2B file and exchange form at s, high- securit y m echanism s, or hardware int erfaces. These sent inels define t he archit ect ure- conform use of t he t echnologies t hey encapsulat e. Pe r iphe r a l t ools. The Convergent Archit ect ure specifies t he t ools t hat direct ly influence t he crit ical developm ent workflow s ( see Chapt er 6) . However, ot her t ools and t heir underlying t echnologies exist t hat influence I T developm ent and operat ions indirect ly ( or peripherally) . These t ools st ill have an im pact on t he effect iveness and qualit y of t he I T landscape as a w hole and m ust be addressed by a holist ic

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

archit ect ure. Exam ples of peripheral t ools include e- m ail syst em s, t ext processing t ools, backup syst em s, and virus checkers. These sent inels ensure t hat no t ool is int roduced int o an organizat ion wit hout addressing it s long- t erm , full- cycle effect from t he I T perspect ive. These sent inel cat egories are used by t he archit ect ure organizat ion ( see Chapt er 5) t o m it igat e risks due t o ext ernal t echnologies ( bot h new and old) t hat cannot be addressed explicit ly in advance by t he archit ect ural st yle. I n t he int erest of holist ic archit ect ure, t he st yle specifies how t hey w ill be handled appropriat ely in t he given inst ance using sent inels. The I T organizat ion now has a m eans t o ensure uniform ly clean, high- ret urn use of t echnologies across it s ent ire I T landscape. [ 2]

I DE is an acronym for int egrat ed developm ent environm ent , m ade popular in t he I T field by m ainst ream program m ing I DEs. I T- archit ect ural I DE m ay be abbreviat ed t o archit ect ural I DE when t he I T cont ext is clear. [ 3]

Oft en referred t o as business- t o- cust om er ( B2C) int eract ion.

[ 4]

Oft en referred t o as ent erprise applicat ion int egrat ion ( EAI ) and business- t obusiness ( B2B) int eract ion, respect ively. [ 5]

See t he Convergent Archit ect ure Web sit e, www.Convergent Archit ect ure.com , for proj ect ions t o furt her J2EE/ EJB servers as w ell as t o ot her im plem ent at ion fram eworks. [ 6]

As explained lat er in t his book, I call a person who is effect ively fulfilling t he role of archit ect according t o t he Convergent Archit ect ure a convergent archit ect .

Th e Ope r a t ion a l En vir on m e n t Successful archit ect ure in any field pragm at ically m ust t arget exist ing operat ional environm ent s. The archit ect ure should enable an organizat ion t o m ake low - risk evolut ionary changes in it s operat ional environm ent inst ead of high- risk radical m odificat ions. I n addit ion, it m ust perm it an organizat ion t o leverage reliable, cost effect ive operat ing t echnology. This m eans rigorously avoiding t he t em pt at ion of t rends, m arket ing illusions, or wishful t hinking at all t im es. The Convergent Archit ect ure defines an operat ional environm ent t hat m eet s t hese crit eria. I t prom ot es t he m ove t o a st andard- based environm ent wit h I nt ernet - cent ric com ponent t echnology. However, first and forem ost , it shows how exist ing syst em s and ext ernal providers can be leveraged in a noninvasive fashion t o becom e part of a convergent syst em . Figure 2.4 sum m arizes how t he Convergent Archit ect ure covers all t he bases of ent erprise I T int egrat ion in t he operat ional environm ent . I t is deceivingly sim ple. However, as described below, t he convergent com ponent s in t heir respect ive roles m eet all t he requirem ent s. Such sim plicit y is one of t he m aj or benefit s of working out t he I T- archit ect ural st yle first , before diving int o individual proj ect s.

-58-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Figur e 2 .4 : The operat ional environm ent . The elem ent s in t he figure represent t hose found in any I T infrast ruct ure. Som e organizat ions w ill have m ore of one elem ent t han anot her, of course. At t he far left of t he figure are t he exist ing syst em s, packaged syst em s, and ext ernal I nt ernet syst em s, including I nt ernet m arket places and applicat ion service providers ( ASPs) . The cent er of t he figure shows t he convergent com ponent s cont ained by a J2EE/ EJB cont ainer. [ 7] At t he right are exam ples of diverse user access channels. All elem ent s are shown working t oget her t o form a single convergent syst em . A convergent syst em is defined as any operat ional syst em based on t he Convergent Archit ect ure. Moving from left t o right , t he figure indicat es t hat ext ernal syst em s, whet her I nt ernet or ot her ext ernal syst em s, are em braced as part of t he convergent syst em via t he syst em - int erface accessors ( SI - accessors) . The SI - accessors are com ponent s t hat cleanly encapsulat e t he special int eract ion requirem ent s of ext ernal syst em s. They are m odel- driven, which m eans t hat t hey are m odeled in UML and generat ed in part or in whole from t he m odel. The SI - accessors are wit hin t he archit ect ural boundary. This boundary, indicat ed by t he large rect angle in t he figure, delim it s t he elem ent s t he archit ect ure has under it s design cont rol from elem ent s it cannot influence direct ly—t he ext ernally developed t echnology, as described earlier. The archit ect ure m ust int erface and adapt cleanly t o t he ext ernal syst em s t o preserve it s own int ernal int egrit y. This is achieved w it h t he SI accessors. The archit ect ure- ext ernal side of t he SI - accessors localizes and defines t he int eract ion wit h ext ernal syst em s, whereas t he archit ect ure- int ernal side provides t he com ponent s of t he convergent syst em w it h com m on, well- form ed st ruct ural and behavioral charact erist ics. This allows all ot her com ponent s wit hin t he archit ect ure t o be m odeled and generat ed uniform ly t o leverage ext ernal syst em s w it hout knowing t he part icular idiosyncrasies of t hose ext ernal syst em s. I t allows exist ing syst em s t o be int egrat ed quickly as part of t he overall convergent syst em wit hout having t o first redesign such syst em s according t o t he Convergent Archit ect ure. For exam ple, packaged applicat ions for finance and adm inist rat ion ( F&A) , ent erprise resource planning ( ERP) , product ion planning syst em s ( PPS) , or ot her m odules from , for exam ple, t he com pany SAP can each be leveraged fully by convergent com ponent s via SI - accessors. This t ype of uniform syst em int egrat ion is oft en referred t o as ent erprise applicat ion int egrat ion ( EAI ) . However, t he sam e schem e applies for business- t o- business ( B2B) com m unicat ions wit h syst em s on

-59-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

t he I nt ernet . I nt ernet banks, ASPs, I nt ernet m arket places, and exchanges each becom e a m odel- driven SI - accessor t hat t hen can be used t ransparent ly by all convergent com ponent s. I n t he Convergent Archit ect ure, t his t ype of int egrat ion wit h I nt ernet syst em s is sim ply a logical ext ension of EAI int o t he I nt ernet , or I nt ernet EAI ( i- EAI ) . The ent it ies labeled as organizat ions, processes, and resources in t he cent er of t he figure represent elem ent s of t he organizat ion's core business m odel. Direct ly below t hem are t he convergent com ponent s t hat direct ly represent t he elem ent s of t he business m odel wit hin t he I T syst em . These com ponent s use, on t he one side, t he SI - accessors t o int eract wit h t he ext ernal syst em s and, on t he ot her side, t he socalled user- int erface accessors ( UI - accessors) t o int eract wit h hum ans. This syst em - t o- hum an int eract ion aspect is shown t o t he right of t he figure. I n addit ion t o t he classic user int erfaces in local area net works, t he int eract ion wit h hum ans via diverse I nt ernet com m unicat ion channels, such as Web browsers and m obile assist ant s, has becom e very significant . This t ype of int eract ion is oft en called m ult ichannel business- t o- client ( B2C) int eract ion. Com plicat ing t he m ult ichannel aspect are t he m any look- and- feel t echnologies possible for each of t he possible com m unicat ion channels. To com m unicat e wit h any given client , t here m ay be several different look- and- feel t echnologies, such as Hypert ext Markup Language ( HTML) , Wireless Markup Language ( WML) , and XML/ Swing dialect s, j ust t o nam e a few. To be successful in t he I nt ernet Age, convergent syst em s will have t o flexibly handle all t hese form s of hum an int eract ion as w ell as new, current ly unknown form s of int eract ion in t he fut ure. To achieve t his, t he Convergent Archit ect ure int roduces UI - accessor s and UI - represent ers. The design and m echanism s of UI - accessors are congruous wit h t he design and m echanism s of t he SI - accessors. I n fact , t hey are ident ical in alm ost every aspect , which furt her sim plifies t he archit ect ure. The only significant difference is t he requirem ent for m ult iple look- and- feel t echnologies when int eract ing wit h hum ans. This difference is cleanly localized by t he archit ect ure in t he user- int erface represent ers ( UI represent ers) shown at t he right in t he figure, which are also m odel- driven com ponent s. As show n in t he figure, a UI - accessor m ay int eract wit h hum an users via one or m ore UI - represent ers. Bot h UI - accessors and UI - represent ers are present in t he design m odel. This enables a designer t o m odel t he user- int eract ion dynam ics and st ruct ure, including t he int eract ion of t he user int erface w it h business com ponent s, and t hen t o generat e t he end- t o- end infrast ruct ure from t he m odel. Of equal significance is t he docum ent at ion and reusabilit y of t he UI accessor and UI - represent er com ponent s provided by t he m odel. As indicat ed in t he figure, all convergent com ponent s, including t he accessors, are physically locat ed in a J2EE/ EJB environm ent and can access ext ernal syst em s using t he best - available t echnology for t he sit uat ion at hand. The UI - represent ers run wherever t he part icular look- and- feel t echnology requires t his. [ 7]

Or a J2EE/ EJB- t ype environm ent , such as a closely relat ed CORBA com ponent s server. Mapping alt ernat ives t o ot her server infrast ruct ures are discussed in Chapt er 7 and in t he Web sit e chapt er.

-60-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Su m m a r izin g t h e Cu m u la t ive I m pr ove m e n t s The final t ask in creat ing t he roadm ap is t o provide a " big pict ure" sum m arizing how and where m aj or im provem ent s can be harvest ed based on t he Convergent Archit ect ure. This int erim sum m ary of benefit s is im port ant for several reasons. First , t he roadm ap w ill not be used unless it is w ort h t he t rip. Second, alt hough m any experienced developers and I T proj ect m anagers will underst and t he benefit s wit hout t his sum m ary, m any of t he benefit s are not obvious at first glance. Many of t hem are cum ulat ive, wit h t he highest ret urns em erging from t he holist ic com binat ion of elem ent s over t im e: The m usic is oft en in t he concert , not t he individual inst rum ent s. Third, non- I T m anagers and skim m ing readers will find t his digest of t he highlight s very useful.

AM FL Y

Table 2.1 provides a t op- 10- st yle overview of cum ulat ive im provem ent s observed in different inst ances of t he Convergent Archit ect ure. The num bers are conservat ive. Alt hough percent ages are provided t o indicat e t he t im e saved while sim ult aneously producing higher qualit y, t here is no int ent t o infer a high level of m at hem at ical precision. The increases in qualit y are m ore im port ant t han t he increase in speed: Building poor syst em s fast er cannot be our goal. The est im at es are averages based on several years of consult ing experience using t he concept s in various organizat ions. There are neut ral sources out side t he current users of t he Convergent Archit ect ure who also have endorsed t he advant ages slat ed here. However, t he m ain obj ect ive of t his sect ion is t o explain briefly and j ust ify how t hese slat ed im provem ent s are achieved, based on w hat you have already read in t his chapt er. Ta ble 2 .1 : Ove r vie w of Cum ula t ive I m pr ove m e nt s

QUALI TY I N CREASE[ a ]

Business and requirem ent s m odeling

20%

++

Design evolut ion and UML m odeling

30%

+

Web ( B2C) and syst em ( B2B) accessor developm ent

50%

++

I m plem ent , build, deploy cycle

60%

++

Test ing

50%

+

Developm ent t ool environm ent

70%

++

Docum ent at ion

60%

++

Runt im e environm ent

60%

+

Proj ect m anagem ent and developm ent process

50%

+

AREA

[ a]

TE

TI M E RED UCTI ON , ~%

+ = significant .

The area of business and requirem ent s m odeling is concerned prim arily wit h st ruct uring t he way an organizat ion can and should operat e in t he fut ure. The

-61-

Team-Fly®

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

principal challenge at t his level is t o work wit h a group of non- I T- dom ain expert s t o unam biguously form ulat e t he st ruct ures and processes of a business. To be successful, t he business client s m ust underst and t he requirem ent s and t he m odel at t his level. Modeling wit h t he RASC organizat ions, processes, and resources using t he CRC t echnique is so int uit ive t o non- I T- dom ain expert s t hat t hey im m ediat ely feel com fort able wit h t his form of refining and st ruct uring t heir requirem ent s. They can part icipat e act ively in t he responsibilit y- driven design sessions; t hey becom e codesigners of t heir convergent syst em . The walkt hrough/ run- t hrough t echnique is a sim ple and fun way t o debug and verify t he int egrit y of business logic before t im e and effort are wast ed refining am biguous, incom plet e business requirem ent s. The result ing CRC st ruct ure and dynam ic scenarios docum ent com plex business sit uat ions using sim ple visual t echniques alm ost anybody can underst and im m ediat ely. Due t o it s universal underst andabilit y and high- fidelit y represent at ion, it is m uch superior as a proj ect signoff docum ent t han t radit ional t ext ual specificat ions. Because business- I T convergence is preserved in t he subsequent developm ent st eps, t his m odel rem ains valuable as t he high- level docum ent at ion and specificat ion of t he I T syst em . Due t o t he highly hum an- int eract ive nat ure of business and requirem ent s m odeling, t he t im e savings result ing from t he use of t he archit ect ure and it s t ools, while st ill significant , is less here t han t he savings in subsequent developm ent st eps. However, t he concom it ant increase in qualit y is m ore significant t han t he t im e saved. This is so because m any proj ect s fail com plet ely because of problem s in business and requirem ent s m odeling. This em phasizes t he conservat ive nat ure of t he figures in t he t able.

The subsequent area of design evolut ion and UML m odeling concerns t he process of refining a business m odel int o a convergent com ponent m odel. I n cont em porary syst em developm ent , m odels are convert ed from one t o t he ot her during t he process of design. These conversion st eps subsequent ly lose t rack of t he original business m odel from which t hey were derived, if a business m odel even exist ed in t he first place. I n t he Convergent Archit ect ure, t he sequence of m odel conversions is replaced by t he evolut ion of a single m odel: The com ponent s in t he business m odel are t he com ponent s in t he result ing syst em . The refinem ent of t he m odel can be t racked visibly t hroughout t he developm ent process. The developer can m ove freely bet ween each level of t he m odel in increm ent al refinem ent st eps inst ead of m aj or, error- prone conversions. The m odel and it s evolut ion rem ain underst andable. I n addit ion, int elligent verifiers, debuggers, and assist ant s in t he I T- archit ect ural I DE help a developer st ay on t he m ost direct , high- qualit y pat h t oward a convergent syst em . The specific applicat ion of pat t erns and st andards, such as J2EE/ EJB, by t he archit ect ure allows t he t ools t o aut om at e m any of t he error- prone and redundant t asks st ill handled by hand in t radit ional developm ent scenarios. I n m ost , if not all, developm ent organizat ions, t he area of Web and syst em accessor developm ent is st ill at t he level of hand- m ade craft sm anship. This is not only cost ly, but also produces propriet ary, com plex syst em s t hat few underst and. This t ype of hand- craft ed access t o a syst em is a far cry from m odel- driven developm ent . The Convergent Archit ect ure im proves t his sit uat ion by prom ot ing t he design and delivery of syst em access com ponent s t o t he sam e level of m odeldriven developm ent used t o develop t he business com ponent s of t he syst em . The developm ent of bot h UI - and SI - accessors is part of t he I T- archit ect ural I DE in t he

-62-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Convergent Archit ect ure. The UML- based m odeling of syst em access allows a developer t o visually represent , docum ent , and reuse bot h t he st ruct ural and dynam ic aspect s of, for exam ple, a B2C or B2B design. The int eract ions wit h t he convergent com ponent s are also part of t he UML m odel, so code can be generat ed for t he end- t o- end syst em , from t he server- side business com ponent s t o t he user's Web int erface. The st eps in t he im plem ent , build, and deploy cycle t radit ionally have involved ext ensive hand coding, even t hough m any of t hese t asks are highly redundant and repet it ive. The t ools t radit ionally used for each of t hese st eps are ext rem ely generic and unaware of each ot her. As such, t hey are unable t o assist each ot her. I n addit ion, t hese act ivit ies st ill t ake place at a relat ively low , com plex, and errorprone level. For exam ple, cont em porary code design and im plem ent at ion usually are perform ed in a program m ing I DE. UML m odels are st ill used rarely as a proact ive st ruct uring t ool t o guide subsequent code generat ion from t he UML m odel. This is where t he m ut ual awareness of t he developm ent m odel and t he I Tarchit ect ural I DE in t he Convergent Archit ect ure provides ext ensive benefit s. The payoff is in t erm s of t urnaround t im e, st ruct ural qualit y, and reduced coding effort in all t hree st eps of t he frequent ly repeat ed im plem ent , build, deploy cycle. The t ranslat ive generat ion from a verified UML m odel aut om at ically produces m aj or port ions of reliable program code, t he build environm ent , and deploym ent art ifact s. Using t he UML m odel as a basis provides reliable docum ent at ion and ensures t he st ruct ural qualit y of t he im plem ent at ion generat ed. Using t he generat or I DE, t he ext ent of generat ion from t he UML m odel can be increased wit h t im e t o furt her reduce bot h t he cycle t im e and t he cycle qualit y. This also reduces t he num ber of program m ers and t est ers required t o produce a given result . The t ask of t est ing always has been accom panied by an int ensive effort in t est developm ent . There are t wo ways t o reduce t he t est ing effort while increasing qualit y. First , raise t he qualit y of t he code produced in t he first place. Second, sim plify t he definit ion and developm ent of effect ive t est inst rum ent s. The Convergent Archit ect ure addresses bot h t hese areas. The code generat ed is of superior qualit y for t w o reasons. First , UML m odels are verified for t heir st yle com pliance and com plet eness in t he C- REF m odule before being used for code generat ion. Second, t he generat or it self repeat edly produces reliable result s, m uch fast er and wit h fewer errors t han a program m er. This is known as im plicit qualit y because t he source of errors is rem oved t ransparent ly as a by- product of t he developm ent process. Alt hough reduced in m agnit ude, explicit t est ing is st ill required. Such explicit t est s are part icularly im port ant t o verify t hat business logic has been im plem ent ed accurat ely. This requires precise business t est scenarios. The definit ion of business t est scenarios is an aut om at ic result of t he businessm odeling t ask in t he Convergent Archit ect ure. The C- BOM m odule generat es bot h graphical and t abular- st at e flowchart s from t he recorded business run- t hroughs. These can t hen be used t o m odel and generat e t est accessors, leveraging once again—t his t im e in t he area of t est developm ent —t he advant ages of m odel- driven com ponent s and accessors m ent ioned earlier. The end result is not only less t est ing overall, but also well- docum ent ed, higher- qualit y t est s using specificat ions produced aut om at ically by t he dom ain expert s during t he process of business m odeling. An effect ive developm ent t ool environm ent is always required for successful progress in I T proj ect s. However, an adequat e environm ent rarely exist s at t he onset of a proj ect . I n addit ion, t he int ense effort t o develop and int egrat e a m at ure

-63-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

t ool environm ent is chronically underest im at ed. There are am ple account s of proj ect s succum bing t o what is known as " deat h by t ools." This is t he problem addressed by t he I T- archit ect ural I DE in t he Convergent Archit ect ure. Wit h it , t he t ool coverage of t he crit ical developm ent pat h is com plet ely st able before a proj ect st art s. This also m eans t hat t he proj ect effort and risks can be bet t er est im at ed because it is clear how t he proj ect will proceed and how t ools will support t he developm ent . Docum ent at ion always has been a burden for I T proj ect s, oft en result ing in t he product ion of poor user docum ent at ion and lit t le or no design docum ent at ion. The m odel- cent ric, convergent approach of t he Convergent Archit ect ure alleviat es t his burden by producing high- qualit y design docum ent at ion as a by- product of developm ent . The m odel- driven code generat ion ensures t hat t he t echnical aspect s of t he syst em are accurat ely docum ent ed and up- t o- dat e at all t im es— aut om at ically, wit h no ext ra effort . This also increases t he qualit y and usabilit y of t he docum ent at ion. Due t o t he convergence of t he business and t echnical m odels, t he sam e applies t o docum ent at ion of t he business m odel. The business m odel docum ent s t he current business and it s support ing syst em behavior. I t is aut om at ically up- t o- dat e and m ay be used as a basis for t raining lit erat ure and handbooks. The effort required t o adapt developm ent and t ools t o a part icular runt im e environm ent t radit ionally is very high. A proj ect oft en will spend m uch of it s t im e experim ent ing wit h t he best way t o leverage t he select ed runt im e infrast ruct ure, for exam ple, a part icular applicat ion server. This lengt hy t rial- and- error process result s in a zigzag pat h of wast ed program m ing effort , wast ed m odeling effort , and proj ect plan alt erat ions. The generat or cart ridges alleviat e t his problem by defining a place t o reuse and cum ulat ively im prove knowledge on t he runt im e environm ent across proj ect s. The cart ridge packages t he result s of experim ent s done by ot hers and allows a developer t o repeat edly produce effect ive m appings from UML m odels t o t he part icular infrast ruct ure. Moreover, t his infrast ruct ure- specific know ledge is used t o check t he UML m odels t o avoid wast eful zigzagging during t he m odeling phase. The generat or I DE is t hen used t o furt her t une or adapt t he t echnology proj ect ion, t hus reducing t he need t o alt er m odels and hand- writ t en code. The areas of proj ect m anagem ent and t he im plem ent at ion of a developm ent process are broad areas t hat always const it ut e an inexact science. How ever, m uch of t he effort and som e of t he inexact ness are reduced by t he developm ent m odel and, in part icular, t he I T- archit ect ural I DE in t he Convergent Archit ect ure. First , not only is t he developm ent process m ore specifically t uned; it also is support ed explicit ly and aut om at ed by t he I T- archit ect ural I DE. Thus, t he effort required t o im plem ent and support t he process is reduced. Second, t racking t he proj ect from t he proj ect m anager's perspect ive is m ore effect ive and m ore precise. The m odules of t he I T- archit ect ural I DE each present a window int o t he current st at us of design evolut ion. The verifiers in t hese m odules present j ust - in- t im e inform at ion regarding t he com plet ion, int egrit y, and t echnological feasibilit y of t he m odel. The im m ediat e generat ion of a com plet e syst em infrast ruct ure including user access aspect s from a m odel allow s t he developer and t he proj ect m anager t o cont inuously verify t he st at e of t he design at t he m ost reliable feedback level possible—t he level of a deployed, running syst em .

-64-

Convergent Architecture

Chapter 2: The Convergent Architecture Roadmap

Su m m a r y This chapt er present ed t he " big pict ure" and high- level roadm ap of t he Convergent Archit ect ure. I t served as bot h an overview and a com m on reference fram e for use by any st akeholder in proj ect s applying t he archit ect ure. I t also covered t he anat om y of t he archit ect ural st yle, including t he role of it s part s, how t hey are relat ed, and how t hey support one anot her. I t brought t he concept of I Tarchit ect ural st yle t o life by sum m arizing how each of it s four feat ures is realized in t he Convergent Archit ect ure.

Chapt ers 3 t hrough 7 and t he bonus chapt er on t he Web sit e follow t he roadm ap present ed in t his chapt er. Each chapt er det ails a m aj or part of t he Convergent Archit ect ure, following t he sam e order in which t hey were int roduced in t his chapt er. Chapt er 8 is t he place t o go from here if you are anxious t o first see a hands- on t ut orial exam ple using t he Convergent Archit ect ure.

-65-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

Ch a pt e r 3 : Th e Con ve r ge n t Ar ch it e ct u r e M e t a m ode l—Th e vision a n d pr in ciple s of t h e a r ch it e ct u r e Ove r vie w The Convergent Archit ect ure m et am odel defines t he t op- level vision, principles, and rules by which decisions are m ade wit hin t he archit ect ural st yle and it s inst ances. I t const it ut es a com m on reference fram e of engineering and proj ect m anagem ent principles shared by all st akeholders of inform at ion t echnology ( I T) syst em s built according t he Convergent Archit ect ure. The general purpose and posit ioning of t his m et am odel wit hin any I T- archit ect ural st yle w ere described in Chapt er 1. Chapt er 2, t hen, present ed it s role in t he t op- level roadm ap of t he Convergent Archit ect ure and sum m arized it s cont ent s, which consist of t he following m aj or t hem es: ƒ ƒ

ƒ

ƒ

ƒ

ƒ

The t hree pillars of holist ic archit ect ure: proj ect design, business design, and syst em design Convergence and convergent engineering The m achine shop m et aphor Reduced abst ract ion set com put ing ( RASC) Concept ual isom orphism Com ponent m et am orphosis

This chapt er covers t hese t hem es in det ail. I t should be read t o get a firm grasp on t he foundat ions of t he Convergent Archit ect ure. Archit ect s, lead designers, and proj ect m anagers need t o be fam iliar wit h t hese t opics t o properly apply t his I Tarchit ect ural st yle.

Th e Th r e e Pilla r s of H olist ic Ar ch it e ct u r e I t is obvious t hat every I T archit ect ure has som et hing t o do wit h large- scale syst em design. However, a holist ic approach t o I T archit ect ure requires a broader perspect ive. I t also m ust address t he crit ically im port ant areas of proj ect design and business design. Proj ect design says how proj ect s are set up, organized, m anaged, and coordinat ed. This goes beyond what t ypically is known as t he soft ware developm ent process. Business design specifies how a business st rat egy is refined and represent ed t o enable effect ive I T support of t he business. These t hree design areas- proj ect design, business design, and syst em design— play a com plem ent ary role in t he effect ive developm ent of m odern I T syst em s ( see Figure 3.1) . They are int im at ely relat ed, considerably influencing each ot her in m any ways. I f a developm ent proj ect st art s wit hout a well- prepared proj ect design, t hen it should be no surprise when t he proj ect slips due t o coordinat ion problem s. Sim ilarly, if a syst em is developed wit hout a proper business design, t hen it should be no surprise if t he result ing I T syst em s do not support t he business adequat ely. To neglect t he int im at e relat ionships bet ween t hese t hree t hem es is t o ignore

-66-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

significant fact or s influencing large- scale syst em design. Neglect ing any one of t he t hree t hrows t he ot her t wo off balance. The significance of t heir m ut ual reinforcem ent m akes t hem t he t hree pillars of holist ic I T archit ect ure.

Figur e 3 .1 : The t hree pillars of a holist ic archit ect ure. I T- archit ect ure is only com plet e when it covers t hese t hree int im at ely relat ed t hem es. Many of t he problem s experienced by cont em porary I T organizat ions can be at t ribut ed t o t he fact t hat t he areas concerning t he design of a business and t he design of a proj ect are handled in an ad- hoc m anner. At t em pt ing t o design com plex I T syst em s wit hout first designing an appropriat e proj ect organizat ion, it s roles, and it s processes is t he best w ay t o wast e t im e and effort . Sadly, m any I T consult ant s do not possess clear proj ect design concept s when t hey ent er int o an engagem ent , leaving t he crucial proj ect design com ponent up t o t he cust om er, who oft en has lit t le experience w it h m odern I T developm ent . I n such cases, syst em developm ent t akes place wit hout a proper fram e of work, oft en in an unchanneled, chaot ic m anner, result ing in syst em s t hat reflect t his chaos. Even great er problem s can occur when proj ect s are set up using ant iquat ed proj ect m anagem ent m et hods having lit t le t o do wit h m odern I T developm ent . Soft ware developm ent proj ect s have unique requirem ent s. Proj ect m anagem ent organizat ions and t echniques t hat st ill m ay be well- suit ed for t radit ional ( non- I Tcent ric) proj ect s oft en will fail or be ext rem ely inefficient when it com es t o m odern soft ware developm ent . The applicat ion of inappropriat e proj ect m anagem ent principles t o soft ware design is t he single m ost significant reason for t he high failure rat e of soft ware proj ect s. Large com panies and governm ent organizat ions wit h a long t radit ion of proj ect m anagem ent are t he m ost suscept ible t o t his hazard. I t is no coincidence t hat soft w are proj ect s in t hese large t radit ional organizat ions are not orious for t heir ineffect iveness, and t he result ing soft ware is not orious for it s inadequacies. Oft en, t he only count erbalance t o a com plet ely inappropriat e proj ect design in t hese organizat ions is t heir high t olerance of inefficiency and t heir ext ensive cash

-67-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

reserves. I n t he past , t hese cash reserves have been accrued t hrough t radit ional product or service lines t hat had, at m ost , only a t angent ial dependency on I T syst em s. These business unit s could m ake m oney independent of t he qualit y of t heir I T support . This sit uat ion is changing fast . Even t he m ost resilient cash cows in large com panies and governm ent agencies are becom ing crit ically dependent on I T. The cash cow s are becom ing t he vict im s of t he very I T inadequacy t hey subsidized. The t radit ional t olerance of soft ware- inept proj ect design in t hese organizat ions now has led t o a vicious circle t hat already has begun t o t ake it s t oll. A sim ilar sit uat ion exist s in t he area of business design. I n t he burgeoning I nform at ion Age, soft ware no longer j ust support s isolat ed part s of t he business, but t he business in it s ent iret y. Business st rat egies are no longer achievable wit hout int ensive I T support . This m eans t hat business design is now essent ially synonym ous wit h I T design. Business design and I T design can no longer be seen as separat e ent it ies: Fut ure business designs also will be, t o a great ext ent , I T designs. This evolut ion is reflect ed by t he increasing significance of corporat e inform at ion officer ( CI O) posit ions in large organizat ions in recent years. I n fact , m any com panies at t he forefront of t he I nform at ion Age have even abolished t he CI O posit ion in favor of a general I T awareness am ong all em ployees. The ent ire organizat ion, st art ing wit h t he chief execut ive officer ( CEO) , is I T- cent ric: Every em ployee is act ively aware of t he cent ral role I T plays in t he business. I t is obvious, t hen, t hat a successful I T archit ect ure for m odern organizat ions clearly m ust com m unicat e how t he business and it s I T syst em s fit t oget her as one consolidat ed syst em . I t m ust consciously address t he int im at e relat ionship bet ween business and syst em design. Once again, t his is not t he case in t he great m aj orit y of t oday's I T syst em s. The int im at e relat ionship bet ween t he business and it s syst em s has not been a cent ral t hem e in I T developm ent . Tradit ionally, I T developm ent has focused on secluded operat ional problem s of a business, not on t he business design it self. I n fact , m ost organizat ions do not even possess a business design, not t o m ent ion a visible m apping of t he business design t o it s com m ensurat e I T support . Even worse, if you ask five coordinat ors in any large organizat ion t o give you a consist ent pict ure of how t he business works, t hat is, what it s goals and priorit ies are and how t hings w ork t oget her, you will get five very different descript ions. Usually, none of t hese descript ions is consist ent and concise enough t o design an I T syst em . Each of t hese persons has his or her unique perspect ive of t he way t hings should work. There is not hing fundam ent ally wrong wit h t his sit uat ion except for t he fact t hat it is a t errible basis for creat ing an effect ive I T syst em . I f I T syst em s are t o int egrat e t he business, t hen t here has t o be a consist ent m odel of t he business. There is no way t o build an effect ive I T syst em t hat cat ers t o num erous, im precise opinions of how t he business should work. This is why m ost cont em porary I T syst em s are so woefully inadequat e. Som eone m ust be in charge of consolidat ing t he various cross- funct ional opinions int o one big pict ure, one consist ent schem e t hat can be used t o build a syst em t hat support s all t he unit s of an organizat ion—t he ent ire organizat ion, not j ust part s of it . Logically, one of t he persons w ho m ust play a decisive role in creat ing t his big pict ure should be t he I T archit ect , since he or she also m ust ensure t he I T com ponent of t he business m odel, which, as we have seen, cannot be developed as an aft ert hought . They are int im at ely relat ed. Thus, t he I T archit ect m ust possess powerful t echniques and t ools t o assist in developing and evolving t he big pict ure of t he business dom ain in conj unct ion wit h it s support ing I T syst em s.

-68-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

I n t he vast m aj orit y of cases, t he act of business design as part of I T archit ect ure will lead t o an overall increase in business qualit y. The sim plifying conciseness required by I T designs forces a business t o get serious about defining and represent ing how it operat es. The result ing business m odel alone is an im port ant st ep t oward im proving business qualit y, regardless of t he I T syst em . Above all, it unam biguously com m unicat es t o everyone in t he business how t he business w orks. The five business coordinat ors m ent ioned earlier now have one clear m odel inst ead of five different m odels. I f t his business m odel has been developed as part of t he I T archit ect ure, t he corresponding I T aspect s are now visible and posit ioned correct ly as an essent ial part of t he business equat ion. A cont inuous, posit ive cycle of change and feedback can now t ake place—first t he business design, followed by it s I T support , followed by operat ional feedback, leading t o adj ust m ent of param et ers in t he business equat ion. The I T syst em s have now becom e valuable t ools t o represent and opt im ize t he business inst ead of j ust being a t roublesom e source of risk and cost . However, t his cycle of cont inuous opt im izat ion cannot begin unt il business design and syst em design t ake place wit hin t he cont ext of j oint proj ect s. Com bining t hese t hem es int o j oint proj ect s has t he pleasant side effect of rem oving t he t radit ional im pedance w all bet ween business and I T organizat ions. Here again, an appropriat e proj ect design is key t o successfully int egrat ing business and syst em design. Last ly, it is int erest ing t o not e t he relat ionship bet ween t he t hem e of business design and so- called st andard or packaged soft ware. Packaged soft ware com prises a part ial, com m on- denom inat or business m odel t o solve com m on, widespread business problem s. However, m any organizat ions have been seduced int o t hinking t hat t heir ent ire I T needs can be m et adequat ely by using packaged soft w are. This is rarely t he case in m edium and large organizat ions. Usually, t hese organizat ions m ust add value by providing unique product s or services. At som e point , t hese product s and services will require unique I T syst em s t hat m ust be eit her developed from scrat ch or int egrat e packaged soft w are in unique com binat ions. I n t his sense, packaged soft ware can be com pared wit h t he refrigerat ors or washing m achines in a m odern household. These m achines package services required by m ost households. How ever, t here is no packaged solut ion for t he ent ire house. The house m ust m eet t he part icular needs of it s builder. Cust om int egrat ion work is required t o posit ion and int egrat e t he washing m achine and refrigerat or properly int o t he house. The part s in bet ween t he m achines—t he room s, t he cabinet ry, an so on—m ust be cust om - designed. Bot h an archit ect and an archit ect ure are required if t he whole house is t o be const ruct ed effect ively t o m eet t he special needs of t he builder. Most businesses and t heir I T syst em s are orders of m agnit ude m ore com plex t han a house, m aking professional archit ect ure orders of m agnit ude m ore im port ant , above and beyond packaged solut ions. The following sect ions det ail each of t he t hree pillars of a holist ic archit ect ure. The principles in each sect ion are form ulat ed as requirem ent s because t he chart er of t he archit ect ural st yle is t o m eet t hese requirem ent s. These requirem ent s are t hen fulfilled in t he subsequent layers of t he Convergent Archit ect ure. I n addit ion, as will be evident lat er in t his chapt er, t he principles in t he Convergent Archit ect ure m et am odel influence each ot her. This is quit e nat ural because requirem ent s are not necessarily unidirect ional or independent .

-69-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

Pr oj e ct D e sign The proj ect design t hem e is concerned wit h t he opt im al coordinat ion of single and parallel proj ect s operat ing at various levels of an organizat ion. I t m ust address t he needs of consolidat ed business and syst em design. From t he perspect ive of proj ect design, t he archit ect ure should do t he following: ƒ ƒ

ƒ

ƒ

Define t he I T organizat ion st ruct ure, roles, and responsibilit ies before beginning I T proj ect s. Define t he developm ent t eam st ruct ure, roles, and responsibilit ies. Define procedures for t he set up, planning, organizat ion, and coordinat ion of proj ect s. I n part icular: o Proj ect concept ion and boot st rapping. o The soft ware developm ent process in t he cont ext of an I T organizat ion, where m ult iple proj ect s m ay exist in parallel. o Proj ect m anagem ent , in part icular proj ect definit ion, est im at ion, planning, coordinat ion, and t racking. Provide t ool and infrast ruct ure support for t he crit ical proj ect workflow and t he m ost crit ical support ing areas.

Busine ss D e sign The business design t hem e is concerned wit h t he consolidat ion and opt im izat ion of t he ent ire business in conj unct ion w it h consolidat ion and opt im izat ion of it s support ing I T syst em s. From t he perspect ive of business design, t he archit ect ure should do t he following: ƒ ƒ ƒ ƒ ƒ ƒ

Define t he relat ionships bet ween t he business as a w hole and it s I T organizat ion. Show how t he business m odel and I T m odel int eract as part s of t he overall business equat ion and how t o represent t his t o t he various st akeholders in com bined business and syst em developm ent . Show how t o represent t he business st rat egy in t erm s of a business m odel, including it s needs for flexibilit y and change. Define how I T m odels em erge from t he business m odel wit hout losing t rack of t he business m odel. Enable I T syst em s t o be m odeled and evolved t hrough act ive part icipat ion of business- dom ain expert s and I T designers. Provide t ool support for t he act ivit y of business design in close conj unct ion wit h t he design of it s support ing I T syst em .

Syst e m D e sign The syst em design t hem e is concerned wit h sim plifying t he developm ent of effect ive I T syst em s in t he cont ext of an ent ire organizat ion.

-70-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

From t he perspect ive of syst em design, t he archit ect ure should do t he following:

ƒ

ƒ

ƒ ƒ ƒ

[ 1]

Define t he use of unam biguous st ruct ures and m echanism s covering crit ical design areas such as design layers, com ponent s, hum an access, syst em access, applicat ions, and packages. Provide clear developm ent guidelines and const raint s t o m eet t he t echnical requirem ent s of ent erprise syst em s ( for exam ple, t ransact ions, persist ence, securit y, scalabilit y, availabilit y, operat ions) using available t echnology. I n addit ion, it should be as specific as possible in order t o avoid com plexit y due t o am biguit y and t o replace fussy alt ernat ives wit h clear guidelines. Address subt le epiphenom ena. [ 1] Provide t ool and infrast ruct ure support for t he crit ical- proj ect w orkflow and t he m ost crit ical support ing areas. Form ulat e t he insuperable const raint s of run- t im e and deploym ent t echnologies and leverage t his knowledge t o provide highly feasible design st ruct ures and m echanism s. Provide t ool and infrast ruct ure support for t he act ivit y of syst em design in accordance wit h t he proj ect and business design t hem es: m odeling, docum ent at ion, aut om at ion, environm ent , and developm ent flow.

AM FL Y

ƒ

TE

Epiphenom enon: A t erm coined by Douglas Hofst adt er ( Hofst adt er 1979) denot ing em ergent propert ies ( Taylor 1997) of a syst em t hat cannot be at t ribut ed t o a single act or unit ary feat ure wit hin a syst em , but rat her is a cum ulat ive result of com plex int eract ions wit hin a syst em . Adj ect ives used t o explain soft ware or t eam behavior, such as perform ance, reliabilit y, and usabilit y, are usually epiphenom ena.

Con ve r ge n ce a n d Con ve r ge n t En gin e e r in g I n 1995, Dr. David A. Taylor coined t he t erm convergent engineering t o nam e t he vision and t echniques he present ed in his m ilest one book ent it led, Business Engineering wit h Obj ect Technology. I n his book, Dr. Taylor out lines in no uncert ain t erm s why I T syst em developm ent as pract iced t oday will no longer succeed in t he burgeoning I nform at ion Age. He t hen provides a solut ion t o t his dilem m a by clearly explaining t he appropriat e use of obj ect t echnology ( obj ect orient ed t echnology) t o achieve a form of evolut ionary business and syst em design unat t ainable wit h t radit ional t echniques. The cent ral concept of convergent engineering will be described briefly in t he following sect ions. For great er det ail, Dr. Taylor's book should be consult ed as t he ult im at e source of t hese concept s ( Taylor, 1995) . Convergent engineering essent ially is concerned wit h com plet ing t he paradigm shift t o obj ect t echnology in an unadult erat ed m anner and realizing it s full pot ent ial despit e num erous dist ract ions along t he way. You m ay be surprised at t he power of obj ect orient at ion exhibit ed in convergent engineering because it goes beyond what is com m only in use t oday.

-71-

Team-Fly®

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

The essence of convergent engineering is t he consolidat ion, or convergence, of business and syst em design int o a single harm onious whole. The crit ical reliance of t oday's organizat ions on inform at ion t echnology requires us t o t hink of t hem as a single, int im at ely relat ed syst em . The business cannot succeed w it hout t echnology. By t he sam e t oken, t echnological innovat ion drives t he capabilit ies of t he business. However, m ost cont em porary organizat ions t reat business st rat egy and it s I T support as t wo separat e w orlds. These worlds rarely com m unicat e, and when t hey do, t hey do so via obscure, poorly defined channels. This causes a cont inual divergence bet ween t he worlds of business st rat egy and I T st rat egy. Divergence m eans t hat it is not clear how I T really support s t he business. The m apping bet ween t he t wo is at best vague and in m ost cases essent ially unknow n. Norm ally, divergence is synonym ous wit h int ract able syst em com plexit y. This leads t o a m yriad of fam iliar problem s, for exam ple, I T syst em s t hat im pede business change, ad- hoc I T designs, and const ant com m unicat ion problem s bet ween an organizat ion's core business m anagem ent and it s I T depart m ent s. Convergence is t he sim plest solut ion t o t hese crit ical problem s. I t says t hat an organizat ion m ay represent bot h it s business and it s I T design wit h a com m on m odel. This com m on m odel can be viewed from t wo perspect ives, t he business perspect ive and t he soft ware perspect ive, as shown in Figure 3.2. The business and I T st akeholders have t wo views of one com m on m odel. To achieve t his, convergent engineering applies t he sim plifying concept s of obj ect - orient ed design equally t o bot h business and I T design. Hist orically, obj ect - orient ed design has been associat ed wit h sim plifying t he developm ent of I T syst em s. This is an inj ust ice t o t he powerful concept s of obj ect - orient ed design, w hich are a m eans of dealing wit h com plexit y in general and have no inherent connect ion wit h I T. Thus obj ect - orient ed design serves equally well t o sim plify t he developm ent of business m odels. Convergent engineering recognizes and leverages t his st rengt h t o sim plify business m odels. The m ost significant sim plificat ion is achieved by having an obj ect - orient ed business m odel, which can t hen be m apped easily t o obj ect t echnology.

Figur e 3 .2 : Converging business and I T m odels. Convergence = t wo perspect ives of one m odel. To achieve convergence, t he business is m odeled increm ent ally using t he concept s of obj ect - orient ed design one crit ical piece at a t im e. The cent ral obj ect s used in t his process are organizat ions, processes, and resources. Since t he result ing business m odel leverages t he concept s of obj ect t echnology, it also can be used as t he soft ware m odel. This convergence int o a single m odel is m aint ained t hroughout

-72-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

syst em developm ent and even int o t he run- t im e syst em . This is achieved by using I T com ponent s t hat direct ly represent t he m odeled business obj ect s ( t hat is, business organizat ions, processes, and resources) , as shown in Figure 3.3. A syst em based on t hese concept s is called a convergent syst em .

Figur e 3 .3 : The convergent com ponent . Cont em porary business analyst s oft en st ress t he benefit s of " aligning t he business wit h t echnology." I n doing t his, t hey em phasize one of t he m any advant ages of convergence. Clearly, a convergent syst em aligns t he business wit h t echnology in t hat it keeps t rack of how business processes and organizat ions are support ed by t he I T syst em . A change in a business process m ay be realized quickly in t he operat ional environm ent by changing t he corresponding process represent at ion in t he I T syst em . Anot her benefit is t hat t he process of convergent engineering im proves com m unicat ion bet ween business m anagers and t he I T depart m ent . Since t hey refer t o t he sam e m odel, t hey develop a com m on underst anding of organizat ions, processes, and resources. This sim plifies discussions regarding changes in t he business and com m ensurat e changes in t he I T syst em . I n addit ion, due t o t he com m on concept s and language used in bot h worlds, t he I T depart m ent can m ake considerable cont ribut ions t o business opt im izat ion. Anot her advant age is t he reduct ion in developm ent effort and risks. This is so because fewer t ranslat ion st eps are required bet ween t he business concept and t he I T syst em . There is a visible correlat ion bet ween business- dom ain design and t echnical design. Proj ect s no longer have t o t ake t he one- w ay st reet of t ranslat ing business m odels int o t echnical m odels. These t ranslat ion st eps are oft en t he great est source of error, cost , and risk in proj ect s. Despit e it s concept ual sim plicit y, convergence cannot be achieved overnight . This is so because organizat ions and t heir syst em s are already ent renched in t he t radit ional problem s. A rapid overhaul of t he organizat ion and it s I T pract ice is not pract ical. A long- t erm m igrat ion t o convergence is t he only pragm at ic approach. However, each sm all st ep along t he road t o convergence can bring m easurable benefit s. For exam ple, m odern applicat ion and m iddleware vendors are m oving t oward obj ect - orient ed, com ponent - based syst em s. Thus, an archit ect ure t hat focuses on convergent engineering is t he best way t o prepare businesses and I T depart m ent s t o leverage new t echnologies as t hey becom e available in t he m ainst ream I T m arket .

-73-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

Last ly, it is im port ant t o not e t hat , like all ideal m odels, convergent engineering m ay never be com plet ely achievable in it s purest form . This, however, does not reduce it s applicabilit y or value as a basis for I T archit ect ure. This point is em phasized by t he OPEN Group, which refers t o convergent engineering as a basis for it s t hird- generat ion obj ect - orient ed developm ent process, t he OPEN process ( Graham , 1997) . I n sum m ary, convergent engineering is t he cornerst one of sim plificat ion and t he key t o resolving m any of t he pat hologic problem s suffered by I T organizat ions. I t drast ically sim plifies bot h business and soft ware developm ent by consolidat ing t he aspect s t hey have in com m on. I t correct ly recognizes t he obj ect - orient ed paradigm as a universally applicable m eans of sim plificat ion. Consequent ly, t he reader will see m e use obj ect - orient ed concept s in som e unexpect ed places—everyw here from business design, t o proj ect design, t o syst em design. The ubiquit ous use of obj ect orient ed concept s m ay look like t he easy way out , and as a key sim plificat ion, it is.

Th e M a ch in e Sh op M e t a ph or Effect ive I T developm ent requires an operat ional environm ent t o support highly specialized t echniques, t em plat es, and t ools t o be used by t eam s of developers. Sadly, m ost proj ect s st art w it hout such an environm ent and oft en fail for t his very reason. The well- know n concept of a m achine shop exem plifies t he environm ent used in m at ure indust ries t o build com plex syst em s. When com paring t he out set of a t ypical I T proj ect wit h t he out set of a t ypical m achine shop proj ect , it is clear t hat t he I T field has a lot of cat ching up t o do. The Convergent Archit ect ure uses t he sym bol of a m achine shop t o represent it s t arget developm ent environm ent . I t st rives t o provide I T proj ect s wit h an operat ional developm ent environm ent com m ensurat e wit h t hat of a well- run m achine shop. The m et aphor of a m achine shop is part icularly applicable in t he cont ext of an I Tarchit ect ural st yle. This is so because an effect ive m achine shop is always designed wit h part icular t ypes of product s in m ind. I t is sensit ive t o t he st yle of syst em s being built and has been highly t uned t o build such syst em s, for exam ple, m ot ors, boat s, or skis, but not all t hree at once. Thus, in t he I T field, t he effect iveness of a m achine shop can only be achieved realist ically in t he cont ext of an I T- archit ect ural st yle where t he st yle of syst em is also known. Like a m achine shop, t he developm ent process, t ool m odularit y, design part it ions, and skills dist ribut ion all can be t uned t o t he specific requirem ent s of t he st yle. These requirem ent s are form ulat ed in t he archit ect ure and developm ent m odels of t he Convergent Archit ect ure. The fact t hat t hese m odels are not proj ect - specific enables a st yle- effect ive shop t o be built and t uned out side t he lim it ed cont ext of a part icular proj ect and t o be reused by m any proj ect s. Just as in m at ure indust ries, t he shop can be in place and operat ional before a proj ect begins, t hus reducing t im e, cost , and considerable uncert aint y in t he area of proj ect est im at ion and m anagem ent . The m achine shop approach has ot her advant ages. The I T archit ect ure in all it s m any facet s will be best underst ood and applied m ost effect ively in an operat ional environm ent sim ilar t o a m achine shop. I n t his environm ent , relat ively abst ract concept s, such as t he developm ent guidelines, design pat t erns, and st ruct ures of t he archit ect ure, can be experienced direct ly in conj unct ion wit h work cells and t ools support ing t heir proper applicat ion. The shop em bodies t he abst ract form s of archit ect ure as t angible, operat ional form s in a working environm ent t hat can be

-74-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

learned easily and applied effect ively by a w ide audience. Since t he shop is t uned for developm ent according t o a part icular I T- archit ect ural st yle, once a developer has learned how t he shop works, t his know ledge can be reused in ot her proj ect s or t o t rain ot her developers. I n addit ion, each t im e t he shop is used, im port ant feedback is gained t hat leads t o consist ent im provem ent s in t he qualit y of t he shop environm ent . Most cont em porary organizat ions are in dire need of t he m achine shop approach for several ot her reasons. First , when a group of developers get s t oget her at t he onset of a new proj ect , experience shows t hat t hey have a hard t im e agreeing on a com m on approach—t o put it m ildly. Second, even if t hey can agree, t hey are usually not experienced in t he com plex area of t ool design and int egrat ion at t he level of I T archit ect ure. The endeavor t o define t he I T archit ect ure and it s procedures and t hen t o const ruct an effect ive developm ent landscape all wit hin t he cont ext of a proj ect is unrealist ic. Such at t em pt s have led t o t he dem ise of count less proj ect s. Third, experience shows t hat if t his all t akes place wit hin t he fram ework of a single proj ect , t he result ing developm ent environm ent will not be well- suit ed t o ot her proj ect s. Last ly, once t he proj ect is com plet ed, who will m ake sure t hat t he environm ent cont inues t o evolve wit h m odern concept s, t echnologies, and t ools? These point s m ake it clear why m at ure indust ries always st art crit ical proj ect s wit h a well- t est ed m achine shop. St art ing wit hout a m achine shop is equivalent t o experim ent ing: I t alm ost guarant ees t hat not hing will be built effect ively. Moreover, a newly conceived m achine shop is not a whole lot bet t er because high- qualit y, effect ive w ork can only occur in a shop environm ent t hat has been t uned across m any proj ect generat ions. I n sum m ary, t he effect iveness of I T proj ect s can be increased significant ly if t hey begin wit h a well- t uned, st yle- specific developm ent environm ent com parable wit h m achine shops found in m at ure indust ries.

Re du ce d Abst r a ct ion Se t Com pu t in g ( RASC) The principle of reduced abst ract ion set com put ing ( RASC) says t hat t he core abst ract ions of convergent engineering ( t hat is, organizat ions, processes, and resources) form t he basic t ypes wit h which we can m odel all business- dom ain aspect s of a convergent syst em regardless of t he act ual business dom ain. This also includes t echnical businesses, such as m anufact uring and governm ent dom ains. These t hree core abst ract ions can be m apped direct ly t o available t echnology w it h m inim al t ranslat ion loss. Two addit ional abst ract ions com plem ent t he core abst ract ions t o com plet e t he RASC set . These are t he accessors and t he ut ilit y com ponent s. Accessors address t he access t o and from hum an users and ext ernal syst em s. Ut ilit y com ponent s denot e t he purely t echnical ut ilit ies of an I T environm ent . The set of RASC abst ract ions is em bodied by t he convergent com ponent s in t he Convergent Archit ect ure. The RASC organizat ions, processes, and resources ( OPRs) are t he basic building blocks in t he convergent approach. The num ber of dist inct building blocks, as well as t heir t ype, is ext rem ely im port ant from t he perspect ive of a designer. RASC addresses t his aspect of design by proposing a set of generally applicable abst ract ions as t he opt im al set of building blocks for designing and developing convergent syst em s. RASC says t hat t here exist s a cert ain set of building blocks, t he RASC set , t hat enables us t o m axim ize t he expressiveness of m odels while

-75-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

keeping t he m odels sim ple and easy t o underst and. More t han t his set of building blocks would be " t oo m any," which w ould lead t o unnecessary com plexit y and confusion. Fewer building blocks w ould be " t oo few," which would hinder adequat e expression. The RASC building blocks form a pat t ern language consist ing of t his opt im al set of abst ract ions. This set is used consist ent ly in t he Convergent Archit ect ure t o express ( m odel) and build all t hree pillars of a holist ic I Tarchit ect ure, not only t he I T syst em . For exam ple, from t he perspect ive of business design in t he Convergent Archit ect ure, t he t hree OPR building blocks, t hat is, t he core abst ract ions of t he RASC set , have been found t o provide opt im al result s: As show n lat er in t his sect ion, four abst ract ions t urn out t o be t oo m any, and t wo abst ract ions are t oo few.

The int ended analogy wit h reduced inst ruct ion set com put ing ( RI SC) designs in t he hardw are indust ry em phasizes t he benefit s of using a useful set of reduced abst ract ions t o deal wit h com plexit y successfully. The following st at em ent s from " m ips RI SC Archit ect ure" ( Kane, 1988) bear wit ness t o t he sim ilar problem s faced by bot h hardware and soft ware designers and em phasize t he benefit s of what Kane refers t o as " a sim plifying archit ect ure" : ƒ

ƒ ƒ

ƒ

" The uniform inst ruct ion set is easier t o use." " There is a closer correlat ion bet ween inst ruct ion count and cycle count , m aking it m uch easier t o m easure t he t rue im pact of code opt im izat ion act ivit ies." " Program m ers can have a higher confidence in hardware correct ness."

Sim ilarly, by focusing on RASC, corresponding levels of sim plicit y and design effect iveness can be achieved in t he soft ware world. Several aspect s cont ribut e t o t he im provem ent s. First , t he sm all set of effect ive abst ract ions form a sim ple, com m on language t o im prove t he qualit y of discussions and designs. Second, anybody and everybody can underst and t his sm all set easily at t he appropriat e level. Third, t his sm all set of abst ract ions can be refined and t uned over t im e t o produce high- perform ance syst em s while st ill m aint aining t he sim plicit y of m odels. I n addit ion, j ust as w it h RI SC, t he t ools used t o develop and m aint ain t he syst em s can be m ore focused, m ore specific, and m ore highly t uned while st ill rem aining easy t o underst and. Last ly, t he RASC set enables a sm all set of canonical com ponent s, t he convergent com ponent s in t he Convergent Archit ect ure, t o be int roduced and refined over t im e. From t he designer's perspect ive, t he com ponent s are in m any ways analogous t o t he concept of t he canonical C+ + class proposed by Jim Coplien ( 1992) in his book, Advanced C+ + I diom s. The com ponent s sim plify m odeling, m odels as well as code st yle, while enabling m ore effect ive aut om at ic code generat ors. This all adds up t o reduced soft ware ent ropy wit h increased design pow er and design com m unicat ion. I n addit ion t o it s analogy wit h RI SC in t he hardware indust ry, im port ant evidence of a RASC- t ype approach exist s in t he soft ware indust ry. First of all, t he RASC set used in t he Convergent Archit ect ure builds on t he t hree core business abst ract ions proposed in 1995 by convergent engineering. These are t he organizat ion, t he process, and t he resource abst ract ions. Convergent engineering recognized t hree abst ract ions, not t wo and not four, t o provide an opt im al working set . These t hree

-76-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

core abst ract ions and t heir basic relat ionships are shown in Figure 3.4. However, Convergent engineering is not alone in select ing t hese t hree abst ract ions. The respect ed Advanced Net work Syst em Archit ect ure ( ANSA) ( I ggulden, 1994) , t he predecessor and principal basis for I SO Open Dist ribut ed Processing ( ODP) st andards, also recognized a universally opt im al set consist ing of t hree core abst ract ions. I t is int erest ing t o not e t hat bot h t he ANSA/ ODP archit ect s, and Dr. David A. Taylor arrived at a reduced abst ract ion set consist ing of t hree core abst ract ions independent ly of one anot her at approxim at ely t he sam e t im e.

Figur e 3 .4 : I ndependent derivat ions of RASC ( sim ult aneously on different sides of t he world) . Even m ore significant t han t he t im ing and num ber of t hese core abst ract ions is t he sim ilarit y of t heir t ypes, t heir sem ant ic sim ilarit y. [ 2] Not only did t hese experienced designers arrive independent ly at t he sam e num ber of abst ract ions ( building blocks) t o achieve t he opt im um , but also t he t ypes of abst ract ions t hey defined as opt im um are essent ially equivalent . The rigor, subst ance, and reasoning t hat lead t hese t wo groups t o t he sam e result are evident in t he respect ive sources, but t he result s can be observed by com paring t he t w o RASC set s. I n Figure 3.4, t he ANSA agent s clearly fulfill t he sam e role as t he convergent engineering organizat ions. They m anage t he access and life cycle of act ivit ies ( t hat is, processes) and resources. The ANSA act ivit ies clearly correspond t o convergent engineering processes. The act ivit ies t ransform resources, whereas in convergent engineering, it is said t hat t he processes use, consum e, and produce resources—essent ially ident ical. Resources are t he int elligent unit s of work and value com m on even in nam e t o bot h m odels. The only real difference bet ween t he t w o set s is t hat convergent engineering nam es it s abst ract ions using com m on business t erm inology and posit ions t hem in t he cont ext of convergent engineering, whereas ANSA has chosen m ore t echnical t erm s, in part icular t he t erm agent , and has posit ioned t hem in t he cont ext of ODP. The Convergent Archit ect ure recognizes and builds on t he m ut ually confirm ing result s of convergent engineering and ANSA. I n sum m ary, RASC in t he Convergent Archit ect ure builds on t he concept s of convergent engineering and st akes t he following claim : The m ost useful set of abst ract ions t o use in all cases of dom ain m odeling, whet her t he dom ain is a global

-77-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

financial inst it ut ion or a m achine m anufact urer, is organizat ions, processes, and resources. These are em bodied by t heir respect ive convergent com ponent s t hroughout t he ent ire archit ect ure. More t han t hese t hree is t oo m any, and fewer t han t hese t hree is t oo few. Ot her t ypes of abst ract ions are less effect ive. I n addit ion t o t he t hree core business abst ract ions, t wo ot hers exist t o sim plify t he t echnical and access aspect s of design. These are t he ut ilit y com ponent s and t he accessor com ponent s, which also belong t o t he fam ily of convergent com ponent s. [ 2]

I n 1995 I invest igat ed t his sim ilarit y and am convinced t hat neit her part y knew of t he ot her's w ork at t he t im e.

Con ce pt ua l I som or ph ism Part of sim plifying anyt hing is t he consist ent use of fam iliar t erm s and concept s wherever possible. When a concept has been reused in a sim ilar form in t wo different areas, t hen we say t hat concept ual isom orphism has been achieved. [ 3] Concept ual isom orphism in t he area of soft ware developm ent m eans t hat a design concept is applicable in diverse developm ent sit uat ions while st ill m aint aining it s fam iliar form . I t m eans t hat all st akeholders in an I T proj ect can reuse t he concept s and t hat t he know ledge and experience regarding t hese concept s can be reused effect ively in ot her proj ect s. Alt hough t he reuse of t echnology and, m ore recent ly, m odeling languages has becom e widely accept ed as j ust plain com m on sense, t he reuse of design concept s at t he level of I T archit ect ure across proj ect s and dom ains is not yet w idespread. The Convergent Archit ect ure st rives t o raise t he awareness and use of concept ual isom orphism t o t he level of convergent business and I T design. The goal is for t he concept s of t he I T- archit ect ural st yle t o be bot h underst ood uniform ly and applied uniform ly across diverse organizat ions, proj ect s, and t echnologies. There are several different areas where concept ual isom orphism can be used im m ediat ely t o sim plify and opt im ize bot h business and I T design. The first of t hese areas concerns t he applicabilit y of developm ent concept s across all I T proj ect s of an organizat ion and across m ult iple organizat ions. An experienced I T archit ect select s developm ent concept s t hat increase t he effect iveness of developers and syst em s while at t he sam e t im e being equally applicable in any organizat ion, new or old. These are not vert ical, dom ain- specific developm ent concept s. They have t he exact opposit e, horizont al focus. Their goal is t o count er t he effect of t he perpet ual focus on vert ical point solut ions found in m ost organizat ions t oday. Just as a governm ent m ust st rive t o avoid t he disarray of com pounded individual or point solut ions in a societ y, so m ust an I T- archit ect ural st yle help organizat ions t o avoid repeat edly developing vert ical point solut ions t o very general design problem s. To replace redundant point solut ions, archit ect ural concept s are select ed t hat m ay be reused everywhere t o im prove t he vert ical, dom ain- specific syst em s. These concept s solve general problem s at a general level inst ead of expect ing proj ect s t o repeat edly solve t he sam e problem different ly at t he level of specific syst em s. This m ay sound like com m on sense—and it is—but it is not being achieved very oft en in t oday's I T organizat ions. The posit ive side effect of put t ing horizont al, cross- proj ect , cross- funct ional archit ect ure concept s in place is t he creat ion of dom ain- specific syst em s t hat can be underst ood by persons from out side t he dom ain. These syst em s have becom e concept ually com pat ible, and oft en t echnically com pat ible, wit h ones in ot her dom ains. There is a whole lot of room for t hese archit ect ure- level concept s in m ost organizat ions. Subst ant ial

-78-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

im provem ent s are possible in t he ext ensive areas of business m odeling, t echnical det ailing, t echnology m apping, and t ools, for exam ple. The convergent com ponent s are one exam ple of such horizont al concept s in t he Convergent Archit ect ure. The convergent com ponent s m ay be applied equally t o t he convergent represent at ion of hum an organizat ions, for exam ple, a business unit or a t rain st at ion, and t o t he represent at ion of m ore t echnical organizat ions, such as a fabricat ion cell or an aut om obile m ot or. Anot her area where concept ual isom orphism can m ake a big difference is in t he I T organizat ion or I T depart m ent of any com pany. There is no reason why t he I T organizat ion should not becom e part of t he overall business m odel. I f t he I T archit ect can m odel a business, t hen t here is no reason why he or she should not st art by m odeling his or her own business, which is t he business of building I T syst em s. The organizat ion responsible for t his part of t he business is, of course, t he I T organizat ion. I t seem s very reasonable t o expect an I T archit ect t o possess a m odel of his or her own business dom ain as a prerequisit e t o m odeling som eone else's dom ain. [ 4] I f t he sam e concept s are used t o m odel t he I T organizat ion as t hose used t o m odel ot her organizat ions—and t here is no reason why t his should not be t he case—t hen t he pleasant side effect of concept ual isom orphism result s. The m odel shows all st akeholders not only how t he I T organizat ion works, but also how t he design concept s will be used t o m odel and support ot her business organizat ions. I n addit ion, it subst ant iat es t he archit ect ure it self by applying it s own concept s in t he spirit of " pract ice what you preach." As described earlier, t he proj ect design pillar of t he Convergent Archit ect ure requires t his form of concept ual isom orphism . The result is t he I T organizat ion m odel of t he Convergent Archit ect ure, which em ploys t he sam e concept s used t o m odel ot her business dom ains. One of t he m ost significant advant ages of concept ual isom orphism is it s posit ive influence on t he longevit y and usefulness of knowledge. One of t he biggest problem s large organizat ions have t oday is t he short half- life of expensive knowledge. The people who underst ood t he concept s used in one proj ect one year are in anot her proj ect t he next year. The design concept s and t he way t hey w ere applied in t he one proj ect are invariably different in t he ot her proj ect . A sim ple m ove bet ween I T- relat ed proj ect s wit hin a t radit ional organizat ion m akes m uch of t he knowledge from a previous proj ect obsolet e. I f t hese proj ect s used sim ilar concept s in places where t his is readily possible, t hen t he knowledge could be reused and would be m ore valuable t o t he individual as well as t o t he com pany. Thus, shared archit ect ural concept s enable persons who have been involved in one proj ect t o use m ore of t he acquired knowledge lat er on in ot her proj ect s. The longevit y of t he knowledge has been increased. This fuels t he m ot ivat ion t o learn because t he m ileage of learning is increased. This form of concept ual isom orphism is also an indispensable st ep t oward sim plicit y and efficiency in large organizat ions because, wit hout it , nobody, not even t he I T gurus of a com pany, can keep up w it h t he num ber of different design concept s applied across diverse proj ect s. Concept ual isom orphism in I T syst em developm ent does not happen by it self or as a by- product of everyday I T proj ect s. This is so because t hese proj ect s are not concerned wit h t he subj ect of concept ual reuse across ot her proj ect s. Trying t o reapply design concept s from t he narrow problem dom ains addressed by everyday I T proj ect s across m any dom ains will not w ork. To t he cont rary, t his approach would increase soft w are ent ropy rapidly because every proj ect w ould have t o m odify t he design significant ly. I nst ead, it t akes a m aj or concert ed effort t o figure

-79-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

out which concept s can be reused readily and widely as part of an overall archit ect ural approach. I n addit ion, t hese concept s can only be used effect ively when st ruct ured wit hin t he cont ext of an I T- archit ect ural st yle t hat has been designed specifically for t his purpose. For t hese reasons, lit t le concept ual isom orphism in t he area of I T is found in organizat ions t oday. Last ly, concept ual isom orphism is not t he sam e t hing as convergence. I t does not m ean t hat w e should at t em pt t o converge all business dom ains int o a single uniform dom ain. Dom ains are separat ed logically according t o t heir differences. Convergence focuses m ore on t he vert ical int egrat ion wit hin a business dom ain. We converge business- dom ain designs and I T, but we do not t ry t o converge reasonably dist inct business dom ains w it h each ot her. Such at t em pt s would be count erproduct ive because t he result w ould be m ore com plex and less effect ive t han t reat ing t he business dom ains as logically separat e cat egories. Concept ual isom orphism com plem ent s convergence from t he horizont al perspect ive; it says t hat we can reuse m any of t he sam e concept s acr oss diverse business dom ains. I n sum m ary, t he first st ep t o high- value reuse of bot h t echnology and knowledge begins wit h t he use of com m on concept s across diverse proj ect s. This is known as concept ual isom orphism , which provides several significant advant ages. First , it reduces learning effort and increases t he longevit y of knowledge. Second, t he uniform applicat ion of design concept s, abst ract ions, and pat t erns across dom ains perm it s bot h knowledge and t ools t o be im proved increm ent ally t hrough reuse. [ 3]

Am erican Herit age Dict ionary ( 1994) : "i·so·m or ·phism n. 2 . Mat hem at ics. A onet o- one correspondence bet ween t he elem ent s of t wo set s such t hat t he result of an operat ion on elem ent s of one set corresponds t o t he result of t he analogous operat ion on t heir im ages in t he ot her set ." [ 4]

I t is disconcert ing t o see t hat t his is not usually t he case. Most I T consult ant s, in fact , have never at t em pt ed t o m odel t heir own business dom ain.

Com pon e n t M e t a m or ph osis There are few physical or m at erial const raint s t o developing soft ware syst em s. They are indeed " soft " in t hat we can conceivably m anipulat e and grow our designs any way we want . The principle of com ponent m et am orphism invokes an int ent ional analogy wit h t he m et am orphosis of a but t erfly t o express a bet t er way t o m anipulat e and grow soft ware designs. Com ponent m et am orphosis says t hat w e can leverage t he cont ext of an I T- archit ect ural st yle t o creat e act ive soft ware com ponent s t hat assist in t heir own developm ent . As illust rat ed in t he Figure 3.5, a com ponent can becom e an act ive ent it y beginning wit h it s concept ion early in t he analysis process. I t can t hen act ively part icipat e in it s elaborat ion t hroughout it s ent ire life cycle.

-80-

Chapter 3: The Convergent Architecture Metamodel

AM FL Y

Convergent Architecture

Figur e 3 .5 : Com ponent m et am orphosis. Convergent com ponent s act ively support users during a given life- cycle st age and work cont ext .

TE

There is no reason why a com ponent should first spring t o life lat e in t he developm ent cycle, aft er days or weeks of developm ent . I n it s em bryonic st ages, a com ponent can act in concert wit h it s t ool environm ent t o significant ly assist t he developer wit h m any t asks associat ed w it h it s developm ent . This includes such t asks as t he acquisit ion and coordinat ion of analysis inform at ion and business requirem ent s, creat ing and m anipulat ing m odels, and recording docum ent at ion and t est scenarios. I n addit ion, it can act ively ensure t hat a healt hy com ponent is evolving at each st ep along t he way. Based on t he design feat ures in t he m odels of t he I T- archit ect ural st yle, a com ponent can possess knowledge early on in it s developm ent regarding it s st yle- consist ent growt h. I t can use t his know ledge t o check and report on it s st yle- consist ent progress, as if it had an act ive im m une syst em . For exam ple, it can act ively report on t he st ruct ure and qualit y of it s cont ent s, whet her it has adequat e inform at ion t o proceed t o t he next st age, or whet her it s current design provides adequat e support for it s int ended role in t he syst em . The com ponent can t ake an act ive role in m aint aining t he int egrit y of t he overall archit ect ure by ensuring, at every st ep along t he way, t hat it evolves according t o t he I T- archit ect ural st yle. I t can even t ell us whet her it s current design st at us will perm it it t o be m apped appropriat ely t o a part icular t echnology. Com ponent m et am orphosis is indeed possible if t he I T- archit ect ural st yle m eet s t wo principal requirem ent s. First , it m ust st ipulat e how com ponent s evolve in t he developm ent m odel. Second, it m ust provide proact ive support for t his evolut ion in it s t ools and developm ent infrast ruct ure—it s I T- archit ect ural I DE. The process of m et am orphosis can t hen replace t he current m ode of developing soft ware in radical heaves of t ranslat ion and reform ulat ion of inform at ion. Com ponent s can be evolved t hrough st eady st ages of inform at ion enhancem ent and growt h—

-81-

Team-Fly®

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

com parable w it h t he m et am orphosis of a but t erfly. Mot her nat ure achieved t his for t he but t erfly over several m illion years, but we would like t o m ove a lit t le fast er. Com ponent m et am orphosis requires t hat w e sharpen t he t ools of I T developm ent . However, it t urns out t hat sharpening our t ools is probably t he sim plest st ep t o t ake. This is due t o t he ironic im balance bet w een t he syst em s t he I T indust ry develops for ot hers and t he syst em s it develops for it self. As if dut ifully fulfilling t he proverbial t ruism of t he cobbler's children having t he worst shoes, we observe soft ware in m any business dom ains t hat does a m uch bet t er j ob of m anaging inform at ion t han we current ly observe in our own ranks—in t he business of building I T syst em s. I t is a well- kept secret t hat t he analyt ical and inform at ionm anagem ent capabilit ies of com m on finance and account ing syst em s, for exam ple, put cont em porary I T developm ent t ools t o sham e.

There is no good reason for t his sit uat ion. However, t here are reasons. First , I T designers have j ust been t oo busy im proving t ools for ot her dom ains t o do t he sam e in t heir own dom ain. Second, plent y of m oney is being m ade w it hout good t ools. Third, given t he relat ive yout h of t he I T indust ry, cust om ers are not I Tsavvy enough t o readily recognize how rudim ent ary and ineffect ive t he cont em porary t echniques and t ools are. Nor are t hey experienced enough t o suggest —or bet t er, t o insist on—im provem ent s. Fourt h, and probably m ost im port ant , t he " soft ness" of soft w are m akes it possible t o j erry- rig anyt hing at any t im e, m aking t ools appear t o be a luxury. This could not be furt her from realit y, as point ed out in Chapt er 1. Com ponent m et am orphosis requires t hat we finally sharpen our own t ools. I t says t o t ake t he knowledge and experience t hat have been form ulat ed in t he m odels of t he I T- archit ect ural st yle and use t hem t o creat e m ore int elligent com ponent s and t ools. Toget her, t his const ellat ion w ill be t he next best t hing t o cloning an experienced I T archit ect . The com ponent s becom e t he vehicles of archit ect ural knowledge and act ive archit ect ural assist ant s, ready t o help any developer anyt im e. The principles of RASC and t he m achine shop m et aphor are im port ant prerequisit es t o achieving com ponent m et am orphosis. Wit hout RASC, t he com ponent s could not know m uch about t heir role in t he archit ect ure or anyt hing about t heir int ended feat ures as m at ure com ponent s. Wit hout t he m achine shop m et aphor, t ools could not opt im ally leverage t he int elligence of t he com ponent or t he high qualit y of inform at ion it provides. Com bining t he st yle- specific int elligence of t he RASC com ponent s wit h t he synergy of t he m achine shop approach in t he I Tarchit ect ural I DE of t he Convergent Archit ect ure will ensure higher archit ect ural fidelit y even am ong less experienced designers and developers. Com ponent m et am orphosis is not very t rendy. I t precludes for t he m ost part codederived archit ect ure or code- driven m odeling. This is in direct conflict wit h t he socalled round- t rip engineering ( RTE) feat ures current ly endorsed by som e t ool vendors. Com ponent m et am orphosis requires a channeled, archit ect ure- driven approach. Any st ruct ural changes m ade in source code following a m odel- driven code generat ion const it ut e an aft ert hought or ad- hoc change t o t he archit ect ure. Such changes should const it ut e a rare except ion and should be avoided if at all possible. I n any case, t hey should not be encouraged. This is so because t he com ponent and t ools cannot proact ively coach t o t he evolut ion of feat ures when t hey are changed lat e in t he developm ent chain. I n such cases, t he com ponent has no w ay t o ensure a well- balanced, healt hy infrast ruct ure. Such code- level

-82-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

st ruct ural changes bypass t he feat ures of a well- form ed archit ect ure, which begins early in t he developm ent cycle, and revive t he very problem s archit ect ure is int ended t o solve. Consider, for exam ple, j ust one aspect of a com ponent , it s docum ent at ion. Com ponent m et am orphosis m eans t hat t he docum ent at ion of a com ponent w ill be enhanced and m aint ained at every st age of it s developm ent , each st age adding inform at ion regarding use, associat ions, risks, side effect s, and so on. This t ype of docum ent at ion can be com pared wit h t he inform at ion sheet one receives wit h pharm aceut ical product s, such as a box of aspirin. The docum ent at ion is product specific and is of ext rem ely high qualit y. This qualit y cannot be achieved as an aft ert hought . I t is t he result of a long and well- cont rolled process t hat accom panied t he developm ent of t he pharm aceut ical product over it s ent ire life cycle. I f t his process perm it t ed lat e, ad- hoc m odificat ions t o t he product , out side t he defined process, t here would be no way t o ascert ain t he t rue qualit y of t he product or it s docum ent at ion. The m ere fact t hat lat e, out - of- st ream changes are allowed reduces t he credibilit y of any inform at ion regarding t he product , regardless of whet her act ual changes t ake place or not . The docum ent at ion becom es pract ically useless, despit e t he effort involved creat ing it . Sim ilarly, if t he cont rols of archit ect ure- driven developm ent are abrogat ed by arbit rarily m odifying code at t he end of t he cycle, t hen high qualit y cannot be reasonably expect ed. To ensure int egrit y, such changes m ust be m ade t o t he com ponent by ret urning t o t he proper st age of m et am orphosis ( t his is indeed possible in soft ware in cont rast t o t he real world) . The changes can t hen be guided by t he com ponent and t he I Tarchit ect ural I DE t hrough all st ages of developm ent . Changes m ade wit hout ret urning t o t he proper st age of m et am orphosis const it ut e t um or- like growt hs in a design, which m ust be repaired lat er at a high cost . I f t his form of ad- hoc developm ent persist s, t hen t he num ber and size of t he t um ors increase, causing a proport ional degradat ion in t he healt h of t he overall syst em . I n fact , a healt hy com ponent should even resist changes when t hese are at t em pt ed at inappropriat e st ages in it s developm ent . By doing t his, it can proact ively count er soft ware ent ropy and irreparable pollut ion of t he archit ect ure. I n sum m ary, com ponent m et am orphosis requires t hat com ponent s act ively support t heir com plet e life cycle, in an ent ire com m unit y of com ponent s, beginning wit h t he first ident ificat ion of t he com ponent in t he phase of business analysis. Once a com ponent has been ident ified, it act ively assist s t he designer t hroughout it s archit ect ural conform enhancem ent and evolut ion. I t m at ures t hrough t he refinem ent st ages of developm ent from a basic, skelet al com ponent t o a fully funct ional com ponent . This process resem bles t he m et am orphosis of a but t erfly and has been nam ed accordingly.

Su m m a r y This chapt er present ed t he archit ect ural m et am odel of t he Convergent Archit ect ure. As we saw in Chapt er 1, t his is t he highest - level m odel of t he I T- archit ect ural st yle. This chapt er described t he visions and principles of t he Convergent Archit ect ure, which direct ly influence t he form s and m echanism s found in it s subsequent layers. These visions and principles serve t o define t he spirit and goals of t he archit ect ure as a whole. They help diverse st akeholders at all levels of syst em design share a m ut ual underst anding and m ut ual sense of direct ion across all I T proj ect s in an organizat ion. They inst ill a com m on sense of st yle in t he ent ire organizat ion, which

-83-

Convergent Architecture

Chapter 3: The Convergent Architecture Metamodel

result s in m ore effect ive decisions and m ore com pat ible progress despit e highly diverse proj ect s. The sect ions on t he individual principles revealed how im port ant synergies em erge from t he cum ulat ive cont ribut ions of t he principles. They explained how t he vision and t he principles int eract t o influence t he design of t he st ruct ures and m echanism s in t he I T- archit ect ural st yle. The result ing st ruct ures and m echanism s are found in t he developm ent m odel of t he st yle, which is covered in t he next t hree chapt ers.

-84-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Ch a pt e r 4 : Th e Con ve r ge n t Com pon e n t M e t a m ode l—Com pon e n t s a s t h e ve h icle of a r ch it e ct u r e Ove r vie w The developm ent m odel of t he Convergent Archit ect ure is com prised of t hree subdivisions. The first of t hese is t he convergent com ponent s m et am odel, w hich is covered in t his chapt er.

The convergent com ponent m et am odel defines com ponent s as vehicles t hat t ransport t he principles of t he archit ect ural st yle int o elem ent s of concret e design, t ools, and t echnologies. I t form ulat es t he archit ect ural st yle at t he level of com ponent design. I t is a m et am odel because it describes how t o creat e a convergent com ponent m odel t hat leverages part icular st andards ( for exam ple, UML or J2EE/ EJB) and end t echnologies ( for exam ple, applicat ion servers) while fulfilling t he requirem ent s of t he archit ect ural st yle at large. I t s requirem ent s encom pass proj ect , business, and syst em design. As such, t he m et am odel has an im pact on m uch m ore t han j ust t he way com ponent s are st ruct ured. I t influences how t hey are derived, refined, and reused t o achieve m odel- driven developm ent using available st andards and t echnologies such as UML, XML/ HTML, J2EE/ EJB, and Java. [ 1] The archit ect ural I DE described in Chapt er 7 is a prim e exam ple of t he broad influence exercised by t he convergent com ponent m et am odel. Every m odule in t he int egrat ed developm ent environm ent ( I DE) is m ore capable as an archit ect ural assist ant because t he m et am odel defines how such aspect s as business design, proj ect m anagem ent , and t echnology m anagem ent are relat ed at t he level of com ponent developm ent . At a high level of abst ract ion, t he st ruct ures and concept s in t he convergent com ponent m et am odel are independent of part icular st andards and t echnologies. However, it would be cont rary t o t he principles of t he Convergent Archit ect ure t o st op at a high level of abst ract ion. The convergent com ponent m et am odel is explained and applied at ever- increasing levels of det ail as we m ove t hrough t his book. Along t he way, it is int erest ing t o not e how im port ant t he m et am odel is as a visible and driving elem ent of st yle and t o discern it s posit ive influence on t he I T organizat ion, t he developm ent process, and t he archit ect ural I DE. This chapt er present s t he convergent com ponent m et am odel, it s st ruct ure reflect ing t he logic in which t he m odel m oves from abst ract ion t o det ail. Each sect ion addresses aspect s of com ponent st ruct ure, m odeling st yle, pat t erns, and t he t echnology proj ect ion: ƒ ƒ

-85-

Ove r vie w a n d fun da m e nt a ls. This sect ion present s t he underlying concept s and st ruct ure of t he m et am odel. Ar chit e ct ur a l la ye r s. This sect ion out lines m aj or aspect s of t he layered com ponent infrast ruct ure and int roduces t he various t ypes of com ponent s and t heir hierarchical organizat ion.

Convergent Architecture

ƒ

ƒ

Chapter 4: The Convergent Component Metamodel

Com m on a spe ct s of a ll conve r ge nt com pone nt s. This sect ion deals w it h t he basic design and st ruct ures com m on t o all convergent com ponent s t o prepare t he st age for t he subsequent descript ion of individual com ponent s. These com m onalit ies com prise aspect s such as com ponent dim ensions, m odeling st yles, and a t echnology proj ect ion. They address and build on t he concept s known as Model Driven Archit ect ure ( MDA) as current ly envisioned by t he OMG ( MDA 2001) . Convergent com ponent s. This sect ion provides det ailed descript ions of com ponent st ruct ure, m odeling st yle, pat t erns, and t he t echnology proj ect ion of t he following com ponent s: o Asse m bly com pone n t s. The t op- level unit s of design and deploym ent . o

Acce ssor com pone nt s. For m ult ichannel user int erface and syst em int erface access.

o

Conve r ge n t OPR com pone nt s. Represent at ions of business organizat ions, processes, and resources.

o

Ut ilit y com pone nt s. Technical services support ing t he superior layers.

[ 1]

Aspect s t hat we are act ively cont ribut ing t o t he Model- Driven Archit ect ure ( MDA 2001) init iat ive at t he OMG.

Ove r vie w a n d Fu n da m e n t a ls The convergent com ponent m et am odel does not build everyt hing new from t he ground up. Rat her, it uses a solid foundat ion of exist ing concept s and st andards, as shown in Figure 4.1.

Figur e 4 .1 : The foundat ion of convergent com ponent s.

-86-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

To t he left , t his figure shows t hat significant aspect s of t he convergent com ponent s are based on t he concept s of convergent engineering ( Taylor 1995) . Above all, convergent engineering prescribes t he t ypes and m eaning of t he business- relevant com ponent s- organizat ions, processes, and resources. I t defines why and how t hese t ypes of com ponent s are best suit ed t o sim plify bot h t he process of business m odeling and t he soft w are represent at ion of t he business m odel. The UML show n at t he cent er of t he figure is used t o represent t he com ponent st ruct ures, t ypes, and concept s in a st andard, sem iform al m odeling language. Based on t he UML represent at ions, t he com ponent m odels can be com m unicat ed, reused, and m anipulat ed m ore easily by t eam s of developers using m odern t ools. More im port ant , t he UML m odels used for convergent com ponent s serve t o abst ract t he design from t he part icular im plem ent at ion t echnology. The m odel t hen serves as t he basis for aut om at ic infrast ruct ure generat ion using t he t echnology proj ect ion, as int roduced in Chapt er 2. This m odel- cent ric approach t o developm ent is oft en referred t o as a m odel- driven design or m odel- driven archit ect ure. The right of t he figure show s t hat t he J2EE/ EJB specificat ions are used as t he basis for t he reference m odeling st yle. The m odeling st yle, which is covered in m ore det ail lat er in t his chapt er, defines how we effect ively m anage and t une st andards and t echnologies using high- level UML m odels. The t erm reference is also significant and has several im plicat ions here. First , t he reference m odeling st yle provides a concret e proof t hat t he approach works: The reference m odeling st yle can be used by default t o build real syst em s, as will be seen lat er in t his book. However, it also is a learning reference, used t o effect ively t each m odeling st yles and m odel- driven developm ent in det ail. I t also serves as a st art ing point t o build m odeling st yles for ot her plat form s. The reference m odeling st yle docum ent s, in det ail, how com ponent s and t heir relat ionships are unam biguously represent ed in UML. I t provides an im port ant basis for sim pler, m ore expressive designs t hat , in t urn, enable higher levels of m odel verificat ion, t est ing, and code generat ion. The current reference m odeling st yle uses 100 percent J2EE/ EJB. Ot her m odeling st yles also m eet t he requirem ent s form ulat ed by t he Convergent Archit ect ure. For exam ple, in t he cont ext of specific proj ect s, m odeling st yles and t heir respect ive t echnology proj ect ions have been developed for pure Java/ RMI ( not J2EE) , CORBA, and OODB ( Versant enJin) infrast ruct ures. [ 2] A m odeling st yle for t he .NET plat form is clearly possible but has not been at t em pt ed yet . The m odeling st yles, t heir t echnology proj ect ions, and t he corresponding feat ures of t he archit ect ural I DE are evolving in conj unct ion wit h t he MDA init iat ive at t he OMG. This proj ect ed evolut ionary pat h is also indicat ed in t he figure. I t is im port ant t o em phasize t hat our requirem ent for specificit y produces m odeling st yles t hat are int ent ionally sensit ive t o a part icular st andard or plat form . However, specificit y is not necessarily synonym ous wit h count erproduct ive dependence on specific im plem ent at ions. The following sect ions explain how we achieve a best - ofbot h- w orlds approach—m odels t hat serve as precise drivers of high- qualit y t echnology proj ect ions while st ill ret aining m axim um independence from t he individual im plem ent at ions. Using t his approach, t he convergent com ponent s have been m apped t o m any specific J2EE/ EJB cont ainers wit hout changing t he com m on UML m odels of t he business com ponent s and wit hout m it igat ing t he expressiveness of t hese m odels.

-87-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Sum m arizing t his in one sent ence, it can be said t hat t he convergent com ponent s apply st andard UML in t he cont ext of convergent engineering wit h a default t echnology proj ect ion t o J2EE/ EJB. For t his const ellat ion, t he full set of docum ent at ion for t he convergent com ponent m et am odel, including it s reference m odeling st yle, consist s of t he m at erial present ed in t his book plus t he following base specificat ions: ƒ

ƒ ƒ

ƒ

The UML Foundat ion Met am odel Specificat ion The Java 2 Ent erprise Environm ent and t he Ent erprise Java Beans Specificat ion Convergent engineering as described in t he book, Business Engineering w it h Obj ect Technology ( Taylor 1995)

I n t he near fut ure, t he finished works addressing MDA as it evolves at t he OMG ( MDA 2001) The goal is t o always keep up wit h t he newest release of each of t hese specificat ions, of course. Cent ral t o t he convergent com ponent m et am odel are t he convergent com ponent s t hem selves, which define a m eaningful set of nam ed design ent it ies for use t hroughout t he Convergent Archit ect ure. They serve as a focal point for developm ent organizat ions, developm ent act ivit ies, design t echniques, and t ools. There are four dist inct classificat ions or t ypes of convergent com ponent s ( CCs) : assem bly com ponent s, accessor com ponent s, business com ponent s, and ut ilit y com ponent s. A single t ype of convergent com ponent m ay com prise closely relat ed variant s or subcom ponent s. The convergent com ponent s are part it ioned int o archit ect ural layers, which are described in t he next sect ion, followed by sect ions det ailing each t ype of com ponent individually. [ 2]

See t he Convergent Archit ect ur e Web sit e, www.Convergent Archit ect ure.com , for m ore inform at ion on such resources.

Ar ch it e ct u r a l La ye r s The convergent com ponent s form a layered com ponent infrast ruct ure, as depict ed in Figure 4.2. The following list sum m arizes t hese layers, t he convergent com ponent s t hey cont ain, and t he im port ant abbreviat ions for t hese com ponent s before each layer is exam ined in det ail lat er in t he sect ion: ƒ

ƒ

ƒ ƒ

-88-

Asse m bly com pone nt la ye r . Cont ains assem bly com ponent s ( ASCs) . Acce ssor com pone nt la ye r . Cont ains accessor com ponent s ( ACCs) . These accessors are subdivided int o t wo cat egories: t he syst em int erface accessors ( SI - accessors) and t he user int erface accessors ( UI accessor s) . I n addit ion, each accessor com ponent is associat ed wit h one or m ore represent ers, one for each t ype of int erface channel. Busine ss com pone nt la ye r . Cont ains organizat ion ( O) , process ( P) , and resource ( R) business com ponent s, also known as t he OPRs. Ut ilit y com pone nt la ye r . Cont ains t he ut ilit y com ponent s ( UCs) .

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Figur e 4 .2 : The archit ect ural layers. Convergent com ponent s form four layers t o best m anage a design. The int ent of t hese layers is t o reduce undesired coupling while increasing cohesion in design m odels, t ools, and runt im e infrast ruct ures. Each layer corresponds t o one or m ore convergent com ponent t ypes found in t he layer. Thus, t he com ponent t ypes are t he prim ary vehicles for enforcing t hese layers. Each layer is hierarchically superior t o t he ones below it . This m eans t hat com ponent s are used, m anaged, and cont rolled by specific com ponent s in t he sam e layer or t he next higher layer.

The assem bly com ponent s ( assem blies) form t he layer of packaging, dist ribut ion, and inst allat ion in t he archit ect ure. The client s of t he assem bly com ponent s are t he operat ional and adm inist rat ive personnel who inst all and m aint ain t he I T landscape for end users. These com ponent s cont ain t he int elligence required t o inst all, updat e, adapt , and t est an inst allat ion wit hout requiring t he operat ions personnel t o possess det ailed knowledge regarding t he int ernals of t he assem bly. I nst ead, t he assem bly provides operat ional personnel wit h inform at ion and facilit ies t o t une t he inst allat ion and t o m onit or and adj ust t he st eady- st at e operat ion of t he assem bly. From t he perspect ive of t he soft w are developer, t he assem bly m anages all convergent com ponent s required by a part icular business applicat ion and ensures a clean evolut ion of t hese com ponent s int o t he operat ional environm ent . I t int egrat es and int elligent ly m anages every aspect of t he deploym ent process. I t t akes care of t he int eract ion w it h ot her assem blies, including m igrat ional aspect s concerning versions of assem blies. I t proact ively reduces soft ware ent ropy and ensures t he preservat ion of convergence in t he runt im e environm ent . The accessor com ponent s ( accessors) form a layer of int eract ion wit h all ent it ies ext ernal t o t he archit ect ure. They support any t ype of int eract ion channel or

-89-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

t echnology required t o int eract wit h t he ext ernal environm ent . The ext ernal environm ent is part it ioned int o t wo m aj or groups: hum an users and ext ernal syst em s. A fam ily of relat ed accessors exist s for each of t hese groups. UI accessors cat er t o t he special requirem ent s of hum an- t o- syst em int eract ion, whereas SI - accessors cat er t o t he special requirem ent s of syst em - t o- syst em int eract ion. [ 3] From t he perspect ive of t he soft ware developer, accessors are m odeled and developed as first - class, reusable com ponent s of a syst em . Each accessor m anages one or m ore represent er com ponent s, one for each t ype of int eract ion channel or int eract ion t echnology. Thus, a single accessor m ay int eract wit h m ult iple channels. On t he inside, t he accessors encapsulat e t he int eract ion wit h OPR com ponent s in t he next lower layer of t he syst em . An accessor m ay be specific t o a single OPR com ponent , or it m ay be associat ed wit h an assem bly and int eract wit h m any different OPR com ponent s. This all adds up t o a st yle- specific const ellat ion corresponding t o t he well- known m odel view cont roller ( MVC) pat t ern. The use of m any ot her well- know n pat t erns and less com m only known design pat t erns can be observed in t he UML m odeling st yle and t echnology proj ect ion of t he accessors and t he ot her convergent com ponent s. [ 4] The business com ponent s ( OPRs) form a layer of organizat ion, process, and resource com ponent s according t o convergent engineering. They represent t he core business aspect s of t he I T syst em . Their client s are t he accessors and ot her OPRs in t he cont ext of an assem bly. From t he developer's perspect ive, t he OPRs use non- business- relevant ut ilit y com ponent s in t he next low er layer as well as a well- defined m odeling st yle, such as t he J2EE/ EJB m odeling st yle used in t his book, t o represent t he core business funct ionalit y. I n addit ion, t he businessrepresent at ion aspect s of t hese OPRs, t he socalled business dim ension ( discussed lat er) , is explicit ly separat ed from t he purely t echnical- represent at ion aspect s, t he so- called I T dim ension. The ut ilit y com ponent s ( ut ilit ies) form a layer of reusable services t hat are, on t he one hand, indispensable t o t he developm ent and m aint enance of high- perform ance convergent syst em s but , on t he ot her hand, are not provided by st andards or im plem ent at ions of t hese st andards. Other convergent com ponent s use ut ilit y com ponent s as necessary enhancem ent s t o t he capabilit ies of t he underlying st andards. They are also em ployed t o insulat e t he life cycle of t he superior layers in t he archit ect ure from t he very different life cycle and high- risk aspect s of t he im plem ent at ion t echnologies. Based on t he com ponent s and t heir layers as j ust described, Figure 4.3 shows how convergent relat ionships are at t ained bet ween use cases in t he business dom ain and convergent com ponent s. To t he left of t he figure are t he t hree t ypes of usecase m odels em ployed t o represent dist inct aspect s of t he business dom ain. Not e t hat t he business- dom ain part it ions correspond in a very logical m anner t o t he archit ect ural layers and t heir respect ive com ponent t ypes.

-90-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

AM FL Y

Figur e 4 .3 : Convergent m odel- t o- com ponent relat ionships.

TE

The int uit ive convergence illust rat ed in Figure 4.3 sim plifies m any aspect s of developm ent . First , in t he upper left of t he figure, business use- case scenarios capt ure bot h st ruct ural and dynam ic aspect s of t he core business in a business m odel. The business m odel represent s bot h requirem ent s and business ent it ies in t erm s of organizat ions, processes, and resources ( OPRs) . The business OPR com ponent s t hen serve t o m ap t he business m odel direct ly t o it s corresponding represent at ions in t he I T dom ain. The OPR business com ponent s are represent ed in UML. This allows t he OPRs t o be m apped ( proj ect ed) aut om at ically t o a part icular I T infrast ruct ure. The figure also indicat es t hat com m onalit y am ong t he OPRs is cleanly represent ed in a base business com ponent , labeled BC. This and ot her det ails of t he OPRs will be discussed lat er. The cent er and bot t om rows in t he figure show t hat , sim ilar t o business scenarios, syst em - access scenarios are also m odeled and m apped explicit ly t o a corresponding t echnical represent at ion. The left side of t he figure out lines t he requirem ent s and scenarios for hum an int eract ion. The accessor use- case scenarios are represent ed by a UI - accessor m odel in UML. Sim ilar t o t he OPRs, t hese represent at ions are t echnically refined in UML and are t hen proj ect ed ( generat ed) t o a part icular I T infrast ruct ure. The sam e schem a applies t o access t o and from ext ernal, nonhum an ent it ies, as shown at t he lower left in t he figure, where SI - accessors are produced. Just as wit h OPRs, com m onalit y am ong t he accessors is cleanly consolidat ed int o a com m on base accessor com ponent . Last ly, t he archit ect ural layers are also evident in t he figure: The accessors use t he OPRs hierarchically, and t he assem bly is used t o package t he convergent com ponent s. I t is now possible t o show how t he archit ect ural layers cover t he needs of an ent ire I T landscape in bot h m odeling and runt im e environm ent s. The first of t he following t wo figures ( Figure 4.4) is an exam ple of t he runt im e configurat ion for a t ypical epaym ent int erm ediary port al. Figure 4.5 shows how such a runt im e configurat ion is

-91-

Team-Fly®

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

generat ed aut om at ically based on t he convergent com ponent s in a UML com ponent m odel.

Figur e 4 .4 : Exam ple: Com ponent s in an e- paym ent port al.

Figur e 4 .5 : Exam ple: Model- t o- infrast ruct ure relat ionship. I n Figure 4.4, a single assem bly com ponent cont ains t he sum of convergent com ponent s for t he e- paym ent port al. The SI - accessors t o t he left of t he figure encapsulat e t he access idiosyncrasies of t he ext ernal back- end syst em s required by t he e- paym ent port al. Each ext ernal syst em m ay use a different represent er t o serve it s part icular com m unicat ions and form at requirem ent s. However, t hese represent ers use a single SI - accessor for a given t ask. To t he right , a sim ilar scenario applies t o t he UI - accessors. Each UI - accessor m ay serve several different represent at ion channels via it s different represent ers. The OPR com ponent s represent ing core business organizat ions, processes, and resources are sit uat ed in t he m iddle and are accessed via t he accessor com ponent s. These OPRs are t he

-92-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

" decision m akers" t hat det erm ine t he im plem ent at ion of t he business st rat egy. I n t his exam ple, t he process com ponent s delegat e com plex work- flow decisions t o a ut ilit y com ponent specialized in rule- based workflow cont rol. Figure 4.5 illust rat es how m ost of a deployed assem bly com ponent and it s environm ent is derived aut om at ically from convergent com ponent s in t he UML m odel. The bar at t he t op of t he figure indicat es t hat t he ent ire process t akes place in t he archit ect ural I DE ( see Chapt er 8) . The UML m odel of convergent com ponent s creat ed in Rat ional Rose is illust rat ed at t he far left . I n t he m odel, t he classic separat ion of present at ion and business m odels is clearly visible: t he accessors wit h t heir represent ers at t he t op and t he OPR com ponent s at t he bot t om . The accessors and t he OPR com ponent s each have a t echnology proj ect ion t hat , as show n t o t he right of t he UML m odel, m anifest s as a t echnology proj ect ion cart ridge in t he archit ect ural I DE. All arrows em it t ing from t he proj ect ion cart ridge ( or sim ply cart ridge) indicat e art ifact s generat ed on t he basis of t he UML m odel. The proj ect ion cart ridge for J2EE accessors at t he t op generat es all t he art ifact s required for a working Web archive ( WAR) , including it s build and t est environm ent . These generat ed art ifact s are all shown t o t he right of t he cart ridge. At t he bot t om , a cart ridge for WebSphere in conj unct ion w it h Versant enJin generat es t he art ifact s required t o creat e t he rest of t he assem bly. The build and t est environm ent generat ed by bot h t echnology proj ect ion cart ridges is configured t o leverage an advanced Java I DE, in t his case JBuilder, shown at t he lower right of t he figure. JBuilder is used t o im plem ent low- level Java business logic and t o aut om at e t he build, t est , and deploy cycle. The assem bly generat ed in t his J2EE t echnology proj ect ion is a J2EE ent erprise archive ( EAR) , as show n t o t he far right in t he figure. The EAR is deployable as an int elligent unit int o t he com bined WebSphere/ Versant / Tom Cat applicat ion server represent ed at t he far right of t he figure. This sect ion present ed t he " big pict ure" of t he convergent com ponent m et am odel at t he level of archit ect ural layers, t he four convergent com ponent t ypes, and t heir use in bot h runt im e and developm ent environm ent s. The next sect ion m oves down one level of det ail and covers t he m et am odel from t he perspect ive of each convergent com ponent . The discussion begins wit h a descript ion of t he aspect s com m on t o all convergent com ponent s and m oves on t o det ailed explanat ions of each t ype of com ponent in subsequent sect ions. [ 3]

I n m odern I nt ernet t erm inology, UI - accessors cat er t o t he specific requirem ent s of business- t o- cust om er ( B2C) int eract ions, whereas SI - accessors address t he specific requirem ent s of business- t o- business ( B2B) int eract ions, B2X, business process int egrat ion, and Web services. [ 4]

Alt hough pat t erns perm eat e Convergent Archit ect ure, t his is not a book on pat t erns. Som e of t he pat t erns used are well known, som e are recent ly published, and ot hers are unpublished. They are applied in a m at t er- of- fact way t hroughout t he archit ect ural st yle and, in t he int erest of m y focus on archit ect ural st yle, will not be point ed out explicit ly in each inst ance. Out lining each pat t ern and describing how it is used and im plem ent ed w ould const it ut e enough m at erial for an ent ire book it self. For a good st art ing point on m any of t he design pat t erns used by Convergent Archit ect ure, see j ava.sun.com / j 2ee/ blueprint s/ design_pat t erns.

-93-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Com m on Aspe ct s of All Con ve r ge n t Com pon e n t s Several feat ures are com m on t o all convergent com ponent s. Before get t ing int o t he st ruct ural and st ylist ic feat ures, let 's t ake a short look at t he com ponent s from t he econom ic perspect ive of t he I T organizat ion. Convergent com ponent s are im port ant resources of an I T organizat ion. They are nam ed ent it ies consist ing of m anifold m odels, docum ent at ion, and various form s of im plem ent at ion t echnology. They are planned, built or bought , deployed, and m aint ained. They consum e significant t im e and personnel. I n short , t hey are ext rem ely cost ly resources. I n t he int erest of ret urn on invest m ent ( ROI ) , an organizat ion should be sure t hat t hese cost ly resources also t urn out t o be valuable resources. I n order t o m easure and t rack t he value of a resource, it m ust first be visible and have charact erist ics t hat can be m easured. To t his end, all convergent com ponent s are visible and m easurable as m anaged resources of t he I T organizat ion, as you w ill see in t he next chapt er. The em phasis here is on t he t erm resource. Alt hough convergent com ponent s will represent m any aspect s of a business in it s I T syst em s ( for exam ple, organizat ions and processes, as m ent ioned earlier) , t hey all share t he com m on propert y of being a clearly delim it ed resource wit hin t he I T organizat ion. For exam ple, a convergent com ponent represent ing t he sales process in a business syst em is also a resource from t he perspect ive of t he I T organizat ion. The I T organizat ion is t he owner of t his valuable resource and m anager of it s ent ire life cycle, ult im at ely being responsible for it s ROI . This relat ionship showing t hat convergent com ponent s are m anaged resources in t he I T organizat ion is illust rat ed by t he m anaged I T resource at t he t op of Figure 4.6.

Figur e 4 .6 : The t echnology proj ect ion com ponent .

-94-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Aside from t heir com m on hom e as resources in t he I T organizat ion, convergent com ponent s share several st ruct ural and st ylist ic feat ures. These feat ures are grouped int o t wo cat egories, each covered separat ely in t he following sect ions: ƒ

ƒ

Te ch nology pr oj e ct ion com pone nt . This cont ains t he m odeling st yle, guidelines, and art ifact s defining how convergent com ponent s are associat ed wit h specific st andards and im plem ent at ion t echnologies. Com pone n t dim e nsions a nd pe r sona lit ie s. This defines t he basic int ernal st ruct ure of all convergent com ponent s.

The Te ch nology Pr oj e ct ion Com pone nt Figure 4.6 shows t he t echnology proj ect ion com ponent ( TPC) as a cent ral feat ure, com m on t o all convergent com ponent s. The TPC defines how we creat e convergent com ponent s m odels t hat m eet t he following t hree crit eria: 1. They provide a level of ( UML) det ail t hat enables t he aut om at ic generat ion of well- t uned, st andard- based t echnology, including it s build and t est environm ent , from t he m odel: support for realit y- scale m odeldriven aut om at ion. 2. The m odel m ust be expressive enough for power developers, m eaning persons highly skilled in t he respect ive t echnology. I t m ust provide t hem wit h adequat e, powerful t uning feat ures wit hin t he m odel- driven approach so t hat t hese developers will not be t em pt ed t o circum vent t he m odel- driven process. 3. I t s part it ioning and abst ract ion levels m ust perm it effect ive, aut om at ic proj ect ions t o m ult iple im plem ent at ions of a com m on plat form or st andard. 4. Meet ing t hese t hree crit eria at t he sam e t im e is challenging, but it can be achieved by defining, first , an appropriat e m odeling st yle and, second, how t he m odeling st yle will be m apped t o various t echnologies. When a m odel t hat conform s t o a m odeling st yle is m apped t o a part icular t echnology, t his is called a t echnology proj ect ion. The t erm t echnology proj ect ion is also used t o denot e t he definit ion of t his m apping. The TPC represent s a part icular m odeling st yle and it s respect ive t echnology proj ect ions and defines how t hese are relat ed t o t he rest of t he archit ect ure. As indicat ed in Figure 4.6, t he TPC is sit uat ed above t he hierarchy of convergent com ponent s. I t is not it self a convergent com ponent . However, it significant ly influences t he m odeling, refinem ent , and generat ion of t he convergent com ponent s. All convergent com ponent s inherit t he m odeling st yle and it s associat ed t echnology proj ect ions from t he TPC. We call t his t ype of inherit ance st yle- t rait inherit ance because t here is no direct , one- t o- one correspondence bet ween t his com ponent and a single physical com ponent in t he runt im e infrast ruct ure. I nst ead, it im poses t rait s of t he part icular st yle on it s descendant s. Such st yle- t rait inherit ance is designat ed by dashed lines in t he figure. As it s nam e suggest s, t he TPC cont ains det ailed inform at ion about how a m odel and it s t echnology proj ect ion are relat ed. I t is where t he rubber hit s t he road: The TPC m anages ( in t he form of m odeling st yle guidelines and ot her art ifact s) design

-95-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

propert ies and t he developm ent process in order t o preserve m axim um independence from im plem ent at ion t echnologies. The m odeling st yle is a core feat ure of t he TPC. A m odeling st yle is a set of guidelines used equally by syst em developers, developm ent - process expert s, and t ool developers. I t provides a UML profile for nam ed t echnologies. Usually, t hese t echnologies are based on a st andard. The UML profile is a det ailed definit ion of UML m odeling prim it ives based on t he feat ures or on t he UML m et am odel of t he t echnology. Based on t he UML profile, t he m odeling st yle defines t he precise m eaning of t he UML m odeling prim it ives and t he way a designer uses t hem t o m anage and t une real- world infrast ruct ure. I t also provides explicit m odeling ext ensions t o allow power users t o t une syst em s at t he m odel level wit hout coupling t he ent ire m odel t o an im plem ent at ion. The m odeling st yle also possesses inform at ion about t he rest of t he archit ect ural st yle, it s upst ream origins, and t he downst ream int ent , which can be used t o aut om at ically com plet e and t une significant aspect s of a m odel. Needless t o say, UML, as a generalized not at ion and m odeling language, and generalized UML m odeling t ools cannot provide t hese specifics. Such t ools are used rat her t o support one or m ore m odeling st yles.

The m odeling st yle com plem ent s t he generalized UML st andard by adding precise m eaning t o elem ent s of t he UML not at ion relat ive t o t he archit ect ural st yle and select ed t echnologies. I t defines how t hese prim it ives relat e t o t he st ruct ures and behaviors on bot h sides of t he UML m odel in t he developm ent st ream . On t he upst ream side, t he m odeling st yle defines how business concept s are expressed in UML, and on t he downst ream side, it defines how each UML represent at ion influences t he act ual syst em im plem ent at ion. This is analogous t o defining t he playing rules in a part icular sport . I f t he rules are not clear, t hen every gam e is different , com plex, and fraught w it h disput e about what t he rules are. Moreover, it is hard for a t eam t o prepare for t he season if t he rules of t he gam e are not set . Finally, before we can define clear rules of t he gam e, we first need t o know what t ype of sport we are defining t he rules for. The rules required for chess or horseback riding are quit e different from t hose required for rugby or soccer. The analogy drives hom e t he point t hat a m odeling st yle is t he prerequisit e of a well- working developm ent process. I t is also a prerequisit e for developing an archit ect ural I DE t o effect ively support t he developm ent process.

The TPC is key t o enabling t he Convergent Archit ect ure t o achieve t he advant ages of specificit y while avoiding t he dow nside of coupling. I t addresses t he influences of t echnology while rem aining independent of t hese influences. This sounds cont radict ory at first . However, it is not . I t j ust requires due respect for t he designer's paradox ( see Chapt er 2) . Form ulat ed for t he sit uat ion at hand, t he designer's paradox says t hat significant requirem ent s and const raint s due t o a t echnology proj ect ion m ust be accom m odat ed explicit ly by t he archit ect ural st yle ( it s m odels and t ools) in order for t he st yle t o rem ain independent of t hese const raint s. The TPC cont ribut es t o t his goal by addressing how upst ream aspect s of t he developm ent m odels and process m ust be adj ust ed t o flexibly handle t hese downst ream const raint s. I f t his is not done, t hen t he early st ages of design are

-96-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

being carried out in a vacuum , and t he result ing m odels can only be used t o com m unicat e concept s at best . For exam ple, in t he J2EE t echnology proj ect ion, t he TPC defines t he necessary influence of t he EJB com ponent st andard and environm ent s on t he UML m odeling st yle for convergent com ponent s. For a .net t echnology proj ect ion, t he TPC would be different . I t w ould define t he UML m odeling st yle for convergent com ponent s based on t he requirem ent s of t he COM com ponent m odel and ot her const raint s of t he .net environm ent . Each of t hese com ponent st andards, J2EE/ EJB and COM, place m anifold, rigid requirem ent s on t he st ruct ure of t he convergent com ponent s and t hus on t heir respect ive m odeling st yles. I n addit ion, t hese com ponent st andards result in m any subt le but im port ant const raint s on t he w ay developers and t heir t ools work. For exam ple, t he J2EE/ EJB st andard specifies how docum ent at ion properly accom panies code down t o t he exact posit ioning and JavaDoc synt ax of t he docum ent at ion w it hin t he code. This will affect , at som e level, t he way developers docum ent t heir design and how t he archit ect ural I DE acquires, form at s, generat es, packages, and st ores docum ent at ion. The TPC is indeed abst ract , as denot ed by it s dot t ed out line in t he figure, because it m ay t ake on different form s depending on t he part icular t echnology proj ect ion. This flexibilit y of cont ent is required because TPCs will need t o address plat form s in t he fut ure, not j ust t he plat form s we recognize t oday. By default , as you w ill see in subsequent chapt ers, t he TPC defines ( cont ains) t he t echnology- sensit ive UML m odeling st yle in t he form of a specificat ions and guidelines docum ent . I n addit ion, it is associat ed wit h t he corresponding set of t echnology proj ect ion cart ridges and t he support for t hese cart ridges in t he archit ect ural I DE.

There is not hing m yst erious about t he TPC. I t sim ply applies t he fundam ent al obj ect - orient ed principle known as fact oring com m onalit y. I n t his case, st ylist ic aspect s of design relat ed t o it s m apping t o t echnology are being fact ored and packaged; t hat is all. How ever, as show n in det ail in t he bonus chapt er on t he Web sit e, it is im port ant t o not e t hat t he TPC is m ore t han a UML profile as foreseen by t he UML st andard: I t is a UML profile plus det ailed guidelines for t he m odeling st yle and it s com prehensive t echnology proj ect ion. The m odeling st yle const it ut es t he com binat ion of a UML profile and st ylist ic guidelines. [ 5] I m proved qualit y and m ore powerful t ool support are t wo of t he good reasons t o com plem ent UML profiles wit h t he addit ional charact erist ics of t he TPC. Just one exam ple: The obj ect ive is t o represent business invariant s using t he Obj ect Const raint Language ( OCL) ( Warm er 1999) in UML m odels. Bot h t he Java language and t he J2EE/ EJB st andard place const raint s on how such invariant s can be im plem ent ed reasonably in t he runt im e infrast ruct ure. Thus, t he t echnology proj ect ion m ust deal w it h t hese const raint s in order t o generat e working syst em s based on t he m odel. This, in t urn, places a requirem ent on t he m odeling st yle for J2EE/ EJB. The st yle guideline in t his inst ance is: All at t ribut es associat ed wit h an OCL invariant m ust be privat e and exclusively accessible via set and get operat ions. [ 6] Only t hen can t he generat or properly generat e t he code t o check OCL invariant s w it hout com ing int o conflict wit h t he UML m odel. I f t his st ylist ic guideline is defined as part of t he TPC, t hen it can be enforced in t he t ools—t he archit ect ural I DE can bet t er assist t he developer. The next sect ion will look at t he com m on st ruct ural feat ures of convergent com ponent s, including som e exam ples of how t hese look when proj ect ed t o different st andard t echnologies.

-97-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Com pone nt D im e nsions a nd Pe r sona lit ie s At t he highest level of design abst ract ion, all convergent com ponent s also have a com m on int ernal st ruct ure. Figure 4.7 present s t his t op- level anat om y of a convergent com ponent . I t shows t hat every convergent com ponent can be seen as consist ing of quadrant s form ed by part it ioning it int o t w o dist inct dim ensions, t he business and I T dim ensions, each dim ension consist ing of t wo personalit ies, t he client and server personalit ies.

Figur e 4 .7 : Convergent com ponent dim ensions and personalit ies.

Th e Bu sin e ss a n d I T D im e n sion s Every convergent com ponent st art s out as a t echnology- independent represent at ion of a business ent it y in a business obj ect m odel ( BOM) . The charact erist ics of t he BOM and how it is derived will be covered in subsequent chapt ers. The business- relevant aspect s of a convergent com ponent are clearly ident ifiable early in t he developm ent process and should rem ain so t hroughout t he com ponent 's life cycle. I refer t o t hese purely business- relevant aspect s of a convergent com ponent as t he business dim ension. The cont ent and life cycle of t he business dim ension should rem ain independent of all nonbusiness- relevant aspect s of t he syst em . These non- business- relevant aspect s of a com ponent const it ut e it s ancillary t echnical infrast ruct ure. Alt hough t his infrast ruct ure m akes up a significant port ion of a com ponent , it is only t here t o allow us t o support t he business dim ension in a part icular I T environm ent . I refer t o t hese ancillary t echnical aspect s as t he I T dim ension of t he convergent com ponent . Every running convergent com ponent has an I T dim ension, and if t he com ponent has core business relevance ( in cont rast t o pure I T relevance) , it also has an explicit business dim ension. An analogy is perhaps best t o explain t he reasoning behind t hese t w o dim ensions: When you t une a radio, you have t o deal wit h t wo t hings. First , you select t he channel ( cont ent ) you want . This is com parable wit h t he business dim ension. I t is

-98-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

t he cont ent t hat you are concerned wit h in t his dim ension. You do not care how it get s here. The plat form vehicle could be a t elevision, a car radio, a port able radio, what ever. Second, you select t he proper plat form and m ake sure t hat t he recept ion is ok. This is com parable wit h t he I T dim ension. Dealing wit h t he com plexit ies of recept ion, t hat is, t he spect rum of poor t o very good, frequency t ype, locat ion and posit ion of t he ant enna, t he qualit y of receiver, and t he qualit y of sound filt ers are all t echnology- relat ed " annoyances" t hat have not hing t o do wit h t he cont ent . I f you sw ap t he plat form , you st ill get t he sam e cont ent , but wit h different t echnological propert ies. For exam ple, if you swit ch from a wat erproof port able radio t o a living room st ereo, you st ill get t he sam e cont ent , but t he delivery plat form has changed. Swit ching t hese t wo plat form s t o deliver t he sam e cont ent is equivalent t o swapping t echnology proj ect ions in t he Convergent Archit ect ure t o deliver t he sam e business dim ension t o different I T dim ensions. Such clear separat ion of dom ain cont ent versus t echnology cont ent is highly desirable but has not been achieved by m any I T syst em s. At t aining t his clean separat ion of concerns is t he int ent of t he explicit recognit ion of business versus I T dim ensions in t he very basis of t he convergent com ponent m et am odel. Put m ore concisely, we ident ify and m aint ain t he following part it ions of a convergent com ponent t hroughout it s life cycle: ƒ ƒ

Busine ss dim e nsion. This dim ension of a convergent com ponent represent s t he core business or dom ain aspect s in t he I T world. This is t he business obj ect being " represent ed" by t he com ponent . I T dim e nsion. This dim ension com prises, quit e sim ply, everyt hing t hat is not part of t he business dim ension. These are t he I T- specific " represent at ion" aspect s of a convergent com ponent . This is t he ancillary part of a convergent com ponent t hat does not cont ain any inform at ion or logic pert aining direct ly t o t he core business.

Alt hough bot h dim ensions always exist , t he business dim ension is only present when required. I f a com ponent is init ially purely t echnical in nat ure, t hen t he business dim ension is sim ply em pt y. I f t his com ponent t akes on business- relevant int elligence at som e lat er st age, t hen t his funct ionalit y is posit ioned in an explicit ly designat ed business dim ension, not j ust anywhere wit hin t he com ponent .

Th e Clie n t a n d Se r ve r Pe r son a lit ie s Each convergent com ponent is part it ioned int o a so- called client personalit y ( CP) and a server personalit y ( SP) . These personalit ies exist t o cleanly encapsulat e and denot e t he t wo design part it ions inevit ably required of any com ponent if it is t o be dist ribut ed. They exist t o opt im ally support a com ponent 's use and reuse wit hin a dist ribut ed environm ent . The client and server personalit ies perm it a com ponent t o be physically dist ribut ed while rem aining logically int act , t hat is, logically cent ralized. This enables a design t o support t he inevit able com ponent - specific opt im izat ions for use in a dist ribut ed syst em w it hout becom ing unduly com plicat ed, as will be shown by t he following exam ples. The act ual dist ribut ion of t he convergent com ponent is opt ional but always possible. I t is int ended by t he base design but not required, t hus providing t he designer w it h m axim um flexibilit y.

-99-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

The principal j ust ificat ion for a client personalit y as a separat e design ent it y is t o provide designers and program m ers w it h a uniform place t o put im port ant client side aspect s of a dist ribut ed environm ent . I t supplies a defined st ruct ure in which t o t une dist ribut ed syst em s wit hout having t o subvert t he encapsulat ion of t he com ponent as a useful design abst ract ion.

Bot h client and server personalit ies m ay have a business dim ension and an I T dim ension, as indicat ed in Figure 4.7. Thus, at t he highest level of abst ract ion, a convergent com ponent consist s of nam ed quadrant s: t he business and I T dim ensions of it s client and server personalit ies, respect ively. How t he business dim ension is dist ribut ed bet ween t he t wo personalit ies depends on t he t ype of syst em and t he part icular role of t he com ponent in t he syst em . Various dist ribut ion m odels oft en are required even wit hin a single assem bly, depending on such t hings as t he num ber and t ype of client s or whet her t he com ponent m ust operat e in a local net w ork, an int ranet , t he I nt ernet , or a nom adic environm ent . For real- world applicabilit y of t he archit ect ure, all t hese dist ribut ion m odels m ust be equally possible wit hin t he com ponent m et am odel because none of t hem can be predict ed in advance of t he part icular assem bly design. The quadrant s of a convergent com ponent in conj unct ion wit h t he archit ect ural layers m ake it easier t o represent and com m unicat e t he design perm eat ions required by dist ribut ed syst em s, including I nt ernet - cent ric syst em s. Figure 4.8 shows how various dist ribut ion m odels are realized using convergent com ponent s wit h t heir respect ive client and server personalit ies. The exam ples in t he figure are j ust point s along a cont inuum bet ween t he t wo poles of 100- percent server- side im plem ent at ion and 100- percent client - side im plem ent at ion. These poles apply not only t o t he physical dist ribut ion of t he com ponent , but also t o t he part it ioning of t he business dim ension bet ween t he client and server personalit ies. Once again, t his is a const ellat ion t hat corresponds t o int erwoven design pat t erns as applied by t he archit ect ural st yle first at t he abst ract design level and t hen at t he level of t echnology proj ect ions t o part icular t echnologies. Several of t hese pat t erns were docum ent ed recent ly in t he cont ext of J2EE ( J2EE Pat t erns 2001) .

Figur e 4 .8 : Enabling various dist ribut ion schem es.

-100-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

AM FL Y

An EJB cont ainer fills t he role of obj ect fact ory shown in t he figure when t he com ponent s are proj ect ed t o J2EE applicat ion servers. J2EE current ly is t he preferred t echnology proj ect ion because it provides st andards ont o which we m ay proj ect any of t hese dist ribut ion const ellat ions. Figure 4.9 shows how, for exam ple, t he ult ra- light weight const ellat ion is proj ect ed t o any J2EE applicat ion server t hat conform s t o t he J2EE blueprint s ( J2EE Blueprint s 2001) .

Figur e 4 .9 : Proj ect ion of an ult ra- light weight client const ellat ion t o J2EE.

TE

The next t wo figures provide a m ore det ailed illust rat ion of t he client and server personalit ies of a com ponent and t heir proj ect ion t o various t echnologies. Figure 4.10 shows how ult ra- light weight const ellat ions are proj ect ed t o J2EE. Figure 4.11 shows how t he personalit ies have been proj ect ed equivalent ly t o a m ixed- language ( Java/ C+ + ) CORBA- based infrast ruct ure.

Figur e 4 .1 0 : Det ail: Ult ra- light weight client const ellat ion t o J2EE.

-101-

Team-Fly®

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Figur e 4 .1 1 : Proj ect ion of a fat client schem e t o a CORBA I nfrast ruct ure ( Java/ C+ + ) . I n Figure 4.10, client personalit ies of an OPR com ponent are shown in an EJB cont ainer. The OPRs are im plem ent ed as ent it y beans and are accessed by a dist ribut ed accessor. The server personalit y of t he accessor is proj ect ed t o a session bean in t he EJB cont ainer. The client personalit y of t he accessor is proj ect ed t o one or m ore Java server pages ( JSPs) and Java classes, bot h of w hich are deployed t o a servlet engine. I n t he figure, t he accessor's client personalit y m anages t hree HTML ( or any ot her light weight prot ocol) represent ers t o serve an I nt ernet browser as it s access channel. Figure 4.11 shows t he quadrant s of a convergent com ponent proj ect ed t o a m ixedlanguage CORBA infrast ruct ure t hat also encapsulat es a legacy infrast ruct ure im plem ent ed in em bedded SQL ( ESQL) . The client personalit y shown in t he figure corresponds t o t he fat client schem e because it cont ains bot h t he Java/ Swing user access im plem ent at ion and t he ent ire business dim ension. The C+ + server

-102-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

personalit y sim ply serves t o encapsulat e dat abase access and legacy ESQL code and m ake t hese available t o one or m ore fat client personalit ies. We now m ove t o t he next level of det ail for each t ype of convergent com ponent , one sect ion for each of t he four archit ect ural layers. [ 5]

I n current OMG/ MDA t erm inology, t he TPC const it ut es t he core UML m odels ( UML profiles) and t he st andard m appings plus addit ional st ylist ic guidelines and t he respect ive aut om at ion levels of t he t echnology proj ect ion. [ 6]

Which in t heory is always a good idea, but is not always pract ical.

Asse m bly Com pon e n t s Assem bly com ponent s ( assem blies) act ively coordinat e const ellat ions of reusable com ponent s in bot h t he developm ent and deploym ent phases of t he com ponent life cycle. These const ellat ions oft en correspond t o t radit ional applicat ions. The coordinat ion provided by an assem bly also ext ends int o t he operat ional phases of t he life cycle. As show n in Figure 4.12, assem blies const it ut e t he t op- level, m acro unit of syst em packaging and deploym ent . As t he m acro unit s of a syst em , t hey also drive t he m acro planning and developm ent process.

Figur e 4 .1 2 : Assem blies as m acr o unit s. Assem blies are convergent com ponent s t hat exist t o m anage and package ot her convergent com ponent s. Norm ally, assem blies are t he only convergent

-103-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

com ponent s deployed alone as unit s. All ot her convergent com ponent s are deployed in t he cont ext of an assem bly. During t he deploym ent phase, t he assem bly com ponent helps m anage t he inst allat ion process. This concept of an assem bly com ponent corresponds t o t he CORBA com ponent s' ( CCM) definit ion of an assem bly. I n t he J2EE t echnology proj ect ion, an assem bly m aps t o a J2EE EAR. Convergent com ponent s can be reused by several assem blies. I n Figure 4.12, Assem bly 2 uses com ponent s B and C from Assem bly 1. Thus, an assem bly can be referred t o and used by ot her assem blies at t he level of it s convergent com ponent s. However, a convergent com ponent is always owned and m anaged by a single assem bly. Assem bly 1 owns com ponent s B and C. Using a t erm explained in m ore det ail in Chapt er 5, every convergent com ponent has a single resource ow ner. These reuse relat ionships are t racked and m anaged by t he assem bly developm ent t eam ( also defined in Chapt er 5) during syst em developm ent . This explicit ownership ensures t hat t he reuse is m anaged t hroughout t he ent ire life cycle of a com ponent in t he cont ext of a single assem bly. This m eans t hat alt hough individual convergent com ponent s are st ill inst allable unit s, t hey are alw ays inst alled in t he cont ext of an assem bly. The assem bly is responsible for t he int egrit y of t he overall syst em . For exam ple, t o updat e a single resource com ponent in an assem bly, a new version of it s assem bly is inst alled. The assem bly m ay in fact only updat e t his single resource com ponent , but t he assem bly also m ust guarant ee t he cont inued int egrit y of it s ent ire developm ent and runt im e environm ent . Guarant eeing such int egrit y is no sm all t ask. This is one reason why t his t ask is clearly assigned t o a com ponent , t he assem bly com ponent , and t o it s corresponding t eam , t he assem bly developm ent t eam ( for det ails, see Chapt er 5) in t he Convergent Archit ect ure.

Acce ssor Com pon e n t s As indicat ed by t heir nam e, accessor com ponent s ( accessors) provide access t o and from ext ernal ent it ies. The definit ion of an ext ernal ent it y is very sim ple: I t is anyt hing t hat is not inst alled as part of an assem bly or part of it s direct runt im e plat form . At t he highest level, it is possible t o dist inguish bet ween t wo basic t ypes of accessor com ponent s. The sim ilarit ies bet w een t hese t wo t ypes act ually out num ber t heir differences, as w ill be seen:

1. Use r int e r fa ce a cce ssor s ( U I - a cce ssor s a nd UI - ACCs) . These are t he m ediat ors bet ween an I T syst em A and a hum an user B. These user int erfaces are not lim it ed t o graphical user int erfaces ( GUI ) ; t hey can also be voice- based, t ext - based, and so on. 2. Syst e m int e r fa ce a cce ssor s ( SI - a cce ssor s a n d SI - ACCs) . These are t he m ediat ors bet ween t wo syst em s A and B. They can be used t o int egrat e different archit ect ures ( syst em int egrat ion) or different inst allat ions ( an int erface bet ween t he inst allat ions of t he sam e syst em in different organizat ions) . Accessors serve t wo im port ant purposes. First , t hey delim it and defend t he archit ect ural boundaries t hroughout t he syst em life cycle. They are used t o coerce and convert t hings ext ernal t o t he archit ect ure int o t hings t hat conform t o t he archit ect ural st yle. This is t he best way—and probably t he only way—t o ensure

-104-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

long- t erm archit ect ural int egrit y no m at t er how m any ext ernal ent it ies are involved in an int egrat ed syst em . Second, t hey separat e t he m odeling of syst em access from t he part icular im plem ent at ion of t he access t o provide developers wit h a clean separat ion of concerns. The separat ion of t he access m odel from it s im plem ent at ion perm it s us t o develop long- lived, reusable m odels independent of t he underlying t echnology and t he life cycle of t he im plem ent at ion t echnology. This separat ion allows developers t o effect ively reuse accessor com ponent s at t he level of UML m odels, t hus prom ot ing t he advant ages of m odel- driven, com ponent - based developm ent int o t he im port ant field of syst em access and syst em int egrat ion. I n addit ion, t he clean separat ion of t he accessor com ponent layer from t he business com ponent layers of t he archit ect ure perm it s different developm ent t asks and roles t o be carried out independent ly: Business- m odel design, applicat ion developm ent , and B2C or B2B design now can be perform ed by different , specifically t rained specialist s using specialized t ools. This im proves flexible adapt at ion, reuse, and m aint enance at m any point s in t he syst em life cycle. For exam ple, wit h t his separat ion of concerns, it is possible t o redesign t he t ype of user access or ext ernal syst em access at t he UML level wit hout t ouching t he business com ponent behind t he scenes. By t he sam e t oken, new use cases can be realized and new user int erface t echnologies can be leveraged wit h lit t le or no change t o exist ing accessor m odels. To dat e, t he I T indust ry has been slow t o address m odel- driven developm ent in t his area of user and syst em access—t he t errain covered by accessors. This has not been due t o neglect ; it is sim ply because t he I T indust ry at large has been m ore focused on im proving t he cent ral, server- side aspect s of syst em design. There is not hing am iss here; it j ust m eans t hat t he accessor com ponent s have less st andard infrast ruct ure on which we can base t heir m odeling st yle and it s m odeldriven t echnology proj ect ion. Alt hough t he accessor design leverages t he st andards available in t his space, t hey m ust current ly define m ore of t he m odeldriven infrast ruct ure t han t he ot her convergent com ponent s. For t his reason, t he accessor m et am odel and t he runt im e environm ent , which will be int roduced in t he following sect ions, are t he m ost ext ensive part s of t he Convergent Archit ect ure. The Acce ssor Fr a m e w or k Figure 4.13 illust rat es t he use of accessor com ponent s t o support different channels of access t o a soft ware syst em . I t shows t hat an accessor com ponent act ually consist s of several separat e part s. Many of t hese part s are m odeled separat ely in t he int erest of t he clear separat ion of concerns. However, t hey are int errelat ed as part s w it hin a syst em of pat t erns. Toget her t hey form what is called t he accessor fram ework.

-105-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Figur e 4 .1 3 : The m odel- driven part s of t he accessor fram ework. This figure m anifest s som e addit ional separat ion of concerns t hat has not been m ent ioned yet . First , beginning at t he t op of t he figure, t he accessor fram ework recognizes t hat various form s of access m ay differ only at t he level of t heir ext ernal represent at ion; all ot her aspect s, such as inform at ion cont ent , inform at ion flow, and event flow, rem ain equivalent across t he various represent at ions. I n addit ion, new form s of access m ay arise at any t im e, while ot her exist ing form s m ay be deprecat ed over t im e. Thus, t he m odeling and product ion of t hese various represent at ion channels are encapsulat ed by so- called represent ers. These represent ers run in so- called represent er cont ainers. A represent er cont ainer is anot her im port ant abst ract ion: I t encapsulat es a specific runt im e environm ent for a group of int errelat ed represent ers. For exam ple, an HTML browser is a represent er cont ainer t hat m ay m anage one represent er per HTML fram e. This level of m odel- driven granularit y is required by m odern I nt ernet port als. Not hing less w ill suffice for a m odel- driven product ion of such syst em s. Anot her im port ant advant age t o t his const ellat ion is t hat it perm it s represent ers t o be reused in different accessor m odels. A single accessor m ay support any num ber of represent ers. Figure 4.13 shows t hree represent er channels being support ed by a single UI - accessor. I t also shows a single represent er being support ed by t he SI - accessor. Sim ilar t o represent er cont ainers, accessors are also housed in accessor cont ainers. An exam ple of an accessor cont ainer is a servlet engine or a Java/ Swing fram ework. Based on t his separat ion of concerns in bot h m odeling and runt im e environm ent s, a single, reusable accessor m ay serve significant funct ionalit y t o m ult iple represent at ion channels, t hat is, t o m ult iple represent ers. This is called m ult ichannel access t o a single accessor. Moreover, new channels m ay be added or exist ing ones rem oved at any t im e via t he UML m odel wit hout having t o circum vent , and com prom ise, t he m odel- cent ric archit ect ure. The following sect ions provide m ore det ail on each part of t he accessor fram ework.

-106-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

M ode l- D r ive n Acce ssor s The accessor fram ework int roduced in t he preceding sect ion com plem ent s t he OPR business com ponent s during all phases of a syst em 's life cycle. Thus, w e require a corresponding level of m odel- driven developm ent and I DE support for accessors. To achieve t his, an accessor m odeling st yle wit h t echnology proj ect ion has been defined t o consolidat e available st andards and t he archit ect ural st yle. These are int roduced here, while det ailed guidelines regarding t he accessor m odeling st yle and it s t echnology proj ect ion are present ed in Chapt er 8 as part of t he J2EE/ EJB t echnology proj ect ion com ponent . An accessor m odel is used t o describe t he accessor com ponent s in t he cont ext of an assem bly. Every accessor m odel is an inst ance of t he accessor m et am odel. The accessor m et am odel, in t urn, is an ext ension of t he UML m et am odel. The accessor m et am odel addresses t he view and cont roller aspect s of t he well- known m odelview- cont roller ( MVC) paradigm . I t is used t o m odel int eract ions wit h t he underlying business m odel, which fills t he m odel role in t he MVC paradigm . The accessor m odeling st yle specifies how t o use t he elem ent s of t he accessor UML m et am odel t o creat e a part icular accessor m odel. An accessor m odel defines bot h t he cont rol flow and t he dat a flow t o and from an ext ernal ent it y ( ext ernal as defined previously) . The m odel cont ains t he inform at ion necessary t o generat e deployable accessors and represent ers as part of t he accessor fram ework. This inform at ion includes, for exam ple, aspect s covering display st ruct ure, reading and int erpret ing event s, user or syst em int eract ion, and int eract ion wit h underlying OPR business com ponent s t o handle input or out put . This procedure applies t o bot h UI - and SI - accessors alike. Accessor m odels usually are based on well- defined applicat ion use cases, so- called accessor use cases. These use cases describe how a user in a specific role int eract s wit h t he I T syst em t o perform a specific t ask. I dent ifying accessor use cases is part of t he analysis- by- design workflow covered in Chapt er 6. I n accessor m odeling, t hese use cases are t ransform ed int o accessor com ponent s in UML. Based on t he accessor m odel, t he t echnology proj ect ion t hen generat es an im plem ent at ion and environm ent for a part icular t echnology. The J2EE t echnology proj ect ion generat es, for exam ple, Java server pages ( JSPs) , Java servlet s, HTML represent at ions, and t heir ANT build and t est infrast ruct ure. SI - accessors are ident ical t o UI - accessors from t he m odeling perspect ive. The differences bet ween t he t wo are in t heir respect ive t echnology proj ect ions. The t echnology proj ect ions m ust be different because SI - accessors support various syst em - int erface t echnologies in cont rast t o t he user- int erface t echnologies support ed by t he UI - accessors. To keep t he follow ing sect ions in proport ion, only an overview of t he accessor m et am odel will be present ed, wit h a focus on UI accessors and t heir J2EE t echnology proj ect ion. Ext ensive det ail on t he accessor m et am odel can be found on t he Convergent Archit ect ure Web sit e.

Acce ssor ( M VC Con t r olle r ) An accessor is t he key concept wit hin t he accessor m et am odel. An accessor is a specializat ion of t he UML m et at ype class. I t represent s an ext ernal int erface of a soft ware syst em . Ext ernal int erfaces can be of t wo t ypes: user int erfaces and syst em int erfaces. A ( graphical) user int erface is an int erface t hat enables a

-107-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

hum an user t o int eract w it h t he soft w are syst em . Furt her, a soft ware syst em oft en m ust be int egrat ed wit h ot her exist ing syst em s. The int eract ion bet ween syst em s is m ade possible t hrough syst em int erfaces. Exam ples of such int erfaces are CORBA int erfaces, Java JMS- based com m unicat ion int erfaces, XML- based st andards for ent erprise applicat ion int egrat ion ( EAI ) , and so fort h. All UML foundat ion m odeling const ruct s m ay be used t o describe t he st ruct ure and behavior of an accessor. Thus, accessors can have at t ribut es and m et hods, t hey can be freely associat ed wit h ot her classes, and t hey can inherit from ot her classes and can im plem ent int erfaces.

I n t he cont ext of t he MVC paradigm , an accessor fills t he role of t he cont roller. UML act ivit y/ st at e diagram s are used t o m odel t he dynam ic behavior of an accessor. UML st at es and st ereot ypes have been configured and ext ended especially t o represent accessors. One of t hese UML- conform ext ensions is t he presence of represent ers ( see t he following sect ion) in t he act ivit y/ st at e diagram s. Represent ers are t he part s of an accessor m odel t hat define t he cont ent and dynam ics of an ext ernal int erface. However, t he accessor m odel does not have t o specify explicit ly w het her a represent er is int ended for a user int erface or a syst em int erface. This is im port ant and em phasizes t he sim ilarit ies bet ween m odeling user and ext ernal syst em int eract ion. The select ed t echnology proj ect ion det erm ines whet her a user int erface or syst em int erface is produced based on t he m odel; t he m odel it self m ay be used for bot h. This m eans t hat one m odel pot ent ially can serve bot h user- and syst em - int erface channels. Accessors ext end t he m odel- driven com ponent paradigm int o t he world of syst em and user int eract ion. Accessors, m eaning ent ire accessor m odels, including st ruct ure and dynam ic aspect s, const it ut e com ponent s wit h clear int erfaces t hat m ay be em bedded in ot her accessors' m odels. Thus, t he arbit rary com posit ion and reuse of accessors are possible.

Re pr e se n t e r ( M VC Vie w ) A represent er is used t o m odel an int erface elem ent , in part icular it s input and out put propert ies. I t is a specializat ion of t he UML m et at ype class. As such, it can have at t ribut es, m et hods, and associat ions wit h ot her classes, and so on. An ext ernal int erface m ay consist of one or m ore represent ers. For exam ple, a m ult ifram ed HTML int erface consist s of one represent er per fram e. The accessor m odel handles int eract ions bet ween represent ers. Out put propert ies of a represent er are inform at ion originat ing from convergent com ponent s and being present ed t o t he ext ernal ent it y. For exam ple, out put could be t o a field in a GUI present ed t o a hum an, or it could be t o an elem ent wit hin an XML docum ent t o be present ed by t he represent er for int erpret at ion by an ext ernal syst em . Sim ilarly, input propert ies specify t he input facilit ies t he represent er provides. Based on it s input , t he represent er t riggers act ivit ies in ot her convergent com ponent s. I n t he cont ext of t he MVC paradigm , t he represent er fills t he role of t he view. However, in cont rast t o m ost MVC int erpret at ions, w hen m odeling a represent er, t he designer only specifies t he kind of inform at ion and input facilit ies t o be provided by t he represent er, not t he concret e form and layout of t he inform at ion. The layout , which m ay be derived direct ly from t he m odel inform at ion, is handled in a channelspecific m anner by t he t echnology proj ect ion.

-108-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Acce ssor a n d Re pr e se n t e r Con t a in e r s Accessor com ponent s do not im ply a part icular runt im e environm ent . I nst ead, accessor m odels m ay be m apped t o different runt im e environm ent s. Exam ples of such different runt im e environm ent s are J2EE servlet s ( for exam ple, HTML or WML) , Java applet s, Java/ Swing environm ent s, or port able m obile assist ant environm ent s. As shown in Figure 4.13, t he accessor and represent er cont ainers are abst ract ions of runt im e environm ent s t hat enable us t o m odel and configure im port ant aspect s of t hese environm ent s. An accessor cont ainer provides basic, st andardized runt im e services t hat will be leveraged by t he accessor. This corresponds t o an EJB cont ainer t hat provides st andardized runt im e services for OPR business com ponent s. For exam ple, t he accessor cont ainer norm ally is capable of act ivat ing accessors, m anaging int eract ion wit h t he operat ing environm ent , and providing facilit ies t o m anage com m unicat ion prot ocols in a highly robust , st andardized fram ew ork. An accessor cont ainer also m ay be a cent ral obj ect in a st and- alone applicat ion. Exam ples of such obj ect s include servlet s in t he cont ext of st and- alone Web applicat ions and execut able Java classes t hat creat e and m anage a Swing fram e com ponent . The accessor cont ainer can be seen as t he leading cont roller obj ect in t he MVC paradigm . All ot her accessors are creat ed and m anaged eit her by t he leading cont roller or by an accessor in t he sam e accessor cont ainer. As an abst ract ion for t he t echnical runt im e environm ent , accessor cont ainers norm ally are not visible in accessor m odels. I nst ead, t hey are configured aut om at ically as part of t he t echnology proj ect ion.

A represent er cont ainer is an abst ract ion of a runt im e environm ent for represent ers. An exam ple of a represent er cont ainer is an HTML/ XML browser such as Net scape or I nt ernet Explorer or a WML browser in a port able m obile assist ant . The represent ers in t hese exam ples are t hen t he HTML/ XML pages or WML fram es. Such represent ers oft en exhibit com plex int eract ion relat ionships wit hin t he cont ext of t he represent er cont ainer, such as t he relat ionships bet ween HTML/ XML fram es. Thus, t hese relat ionships m ay be m odeled explicit ly in an accessor m odel. The represent er cont ainer houses and m anages t he act ive represent ers and displays t heir graphic int erface t o users or, in t he case of SI - accessors, provides anot her form of int erface t o t he ext ernal ent it y. Represent er cont ainers m ay be com posed freely t o form a hierarchy of represent er cont ainers. The root cont ainer in t he hierarchy is t he t op- level represent er cont ainer, which is m anaged by it s associat ed accessor cont ainer. Last ly, from t he perspect ive of t he convergent com ponent m et am odel, bot h accessor and represent er cont ainers are ut ilit y com ponent s ( defined lat er) .

Th e Ex t e n de d St a t e M a ch in e M ode l The accessor m et am odel also defines a UML- com pliant ext ension t o act ivit y/ st at e diagram s in order t o m odel t he behavior of an accessor effect ively. This ext ended st at e m achine m odel consist s of several specializat ions of t he UML t ype st at e. These are as follows:

-109-

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 4: The Convergent Component Metamodel

Re pr e se nt e r St a t e . This describes t he st at e of a represent er in a represent er cont ainer. I n a GUI , t he st at e det erm ines whet her input or view elem ent s are t o be displayed. For exam ple, in a syst em int erface, t he t ransit ion t o a Represent erSt at e can t rigger an XML docum ent t o be dispat ched. I n t his case, t he int erface w ould wait for a response docum ent cont aining input inform at ion provided by t he ext ernal syst em . The event s t riggered t hrough input s of a represent er are handled as I nput Event s. I nput Event s can t rigger t ransit ions in t he act ivit y diagram of an accessor. Em be dde dAcce ssor St a t e . This describes a special st at e in t he accessor's act ivit y diagram com posed of m any ( reused) accessors. A t ransit ion t o an Em bedded AccessorSt at e init ializes and act ivat es t he subordinat e accessor. The originat ing accessor rem ains in t he Em beddedAccessorSt at e unt il t he em bedded accessor reaches it s t erm inal st at e. When t he subordinat e accessor reaches it s t erm inal st at e, it t riggers a Term inalSt at eEvent , which usually t riggers a t ransit ion in t he originat ing accessor. Opt ionally, t he originat ing accessor can provide it s own represent er( s) in an act ive represent er cont ainer. I n t his case, t ransit ions t o t he originat ing st at e also can be t riggered by I nput Event s from t he represent er( s) ; t he subordinat e accessor is deact ivat ed w it hout reaching it s t erm inal st at e. Jum pSt a t e . This defines a special t erm inal st at e in t he accessor's act ivit y diagram w here t he accessor hands over cont rol t o anot her accessor, t he j um p t arget . I n cont rast t o t he Em beddedAccessorSt at e, t he current accessor loses cont rol; t hat is, on act ivat ion of t he j um pt arget accessor, t he current accessor is deact ivat ed. I f t he current accessor is em bedded in anot her accessor, it s encapsulat ing accessor w ill be deact ivat ed when a Jum pSt at e in t he act ivit y diagram of t he current accessor is reached. I f t he encapsulat ing accessor is it self an em bedded accessor, t his deact ivat ion m echanism will recurse up t he ent ire act ive accessor st ack. Aft erwards, t he j um p- t arget accessor is init ialized and act ivat ed, now being t he only act ive accessor.

Act ivit ies and decisions are st andard feat ures of UML act ivit y/ st at e diagram s t hat t ake on special m eaning in t he cont ext of an accessor. They are used t o describe all behavioral aspect s of an accessor t hat are not involved in act ivat ing and t ransit ioning bet ween represent ers ( Represent erSt at e) or involved in m anaging accessors ( Em beddedAccessorSt at e or Jum pSt at e) . Typically, act ivit ies and decisions express t he int eract ions of t he accessor wit h it s support ing convergent com ponent s. Act ivit ies and decisions t rigger various ProcessEvent s. I n part icular, act ivit ies can produce Except ion- Event s, which are a special kind of ProcessEvent used t o handle except ional sit uat ions. The except ion- handling m echanism s are det ailed in t he bonus chapt er on t he Web sit e.

Re sour ce M a ppin g Using t he elem ent s described t hus far ( t hat is, special st at es, act ivit ies, decisions, event s, and t ransit ions) , it is possible t o m odel t he cont rol flow of an accessor. To describe t he dat a flow wit hin t he accessor's st at e m odel, t he accessor m et am odel defines t he ResourceMapping abst ract ion. A ResourceMapping is used t o pass param et ers wit hin t he accessor m odel. I n general, a ResourceMapping is a rule for passing a single value from a source elem ent t o a t arget elem ent on t he

-110-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

occurrence of a part icular event . The ResourceMapping consist s of source and t arget references t hat specify t he source and t arget elem ent s, respect ively. A reference is described by a ReferencePat h, which refers t o t he referenced m odel elem ent . The ReferencePat h can be com posed of an arbit rary num ber of ReferencePat hs, t hus form ing a navigat ion pat h t hrough t he m odel. ResourceMappings are used in t he following places: ƒ ƒ

I n Re pr e se n t e r St a t e s. A ResourceMapping in a Represent erSt at e t ypically is used t o m ap values of accessor at t ribut es t o at t ribut es of t he represent er( s) associat ed wit h t hat Represent erSt at e. I n Em be dde dAcce ssor St a t e s. A ResourceMapping in an Em beddedAccessorSt at e t ypically is used t o m ap values of at t ribut es in t he superior accessor t o at t ribut es of t he subordinat e accessor associat ed wit h t he Em beddedAccessorSt at e.

AM FL Y

Furt her levels of det ail are necessary t o com plet ely describe t he m odel- driven accessor com ponent s, t heir m odeling st yle, and t heir t echnology proj ect ions. This det ail is provided in t he bonus chapt er on t he Web sit e, which covers t he ent ire Technology Proj ect ion Com ponent .

OPR Bu sin e ss Com pon e n t s

TE

The business com ponent layer defines a finit e set of com ponent t ypes, t he OPRs, according t o t he principles of convergent engineering and RASC as described in Chapt er 3. The m ost im port ant advant age of t he business com ponent s is t heir business relevance, t he business dim ension, regardless of t heir t echnical represent at ion, t he I T dim ension, which m ay change quit e oft en. The process of m odeling wit h t hese com ponent s helps business and I T expert s com m unicat e, represent , evolve, and t une business operat ions. During t he definit ion of an I T syst em , business com ponent s are first considered from t his business perspect ive. The result ing business m odel is t hen evolved int o an I T infrast ruct ure according t o t he clear pat t erns and rules of t he archit ect ural st yle, t hereby aut om at ically avoiding t he pit falls of com plex t ranslat ion losses and concept ual drift —in ot her words, avoiding divergence. Avoiding divergence is t he j ob of t he convergent OPR com ponent s, each covered in it s respect ive sect ion here. The OPR Bu sin e ss Pe r spe ct ive I n t his sect ion we focus on t he business dim ension of t he business com ponent s. I n addit ion t o t he ext ensive use of obj ect - orient ed design t echniques in t he I T dim ension, t hey are also used at t he level of business design. When applied properly, t he obj ect - orient ed approach sim plifies t he ent ire m odeling process at bot h t echnical and business levels. This is due t o t he fact t hat anybody can learn quickly t o read an obj ect - orient ed m odel. I t is easier t o underst and an obj ect orient ed m odel t han any ot her represent at ion because obj ect orient at ion leverages everyday concept s t hat we are all fam iliar wit h. For exam ple, t he concept of inherit ance, one of t he t hree pillars of obj ect orient at ion, [ 7] and it s power t o sim plify business m odels can be underst ood im m ediat ely even by persons wit h no previous exposure t o soft ware developm ent . Thus, obj ect - orient ed design can be

-111-

Team-Fly®

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

used by anyone t o sim plify bot h t he represent at ion of t he business and t he com m unicat ion of t his represent at ion. However, t here is one cat ch: Som eone st ill has t o define how t hese powerful concept s will be used t o best represent a business as well as it s respect ive I T syst em s. A set of guidelines, t he m odeling st yle, m ust exist t o define how obj ect - orient ed and ot her concept s w ill be applied uniform ly across t he m any proj ect s and syst em s in an organizat ion. I n t he Convergent Archit ect ure, t he m odeling st yle for OPR business com ponent s begins here in t he convergent com ponent s m odel. How ever, it also influences t he act ivit ies of t he developm ent process and t he UML m odeling st yle, bot h covered in lat er chapt ers.

For t he OPR com ponent s, t he m odeling st yle st art s w it h t he business m odel. I t defines a set of m odeling abst ract ions t hat will be used uniform ly in all business m odels. These abst ract ions are t he OPRs, from convergent engineering ( Taylor 1995) . Figure 4.14 uses a t ypical const ellat ion of OPRs t o exhibit how t hey can be used t o represent any business operat ion. Rem em ber, t he t erm business used here is relat ive t o t he dom ain or indust ry. A t echnical business dom ain also m ay be represent ed using t he OPR abst ract ions.

Figur e 4 .1 4 : Business engineering wit h obj ect t echnology.

-112-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

I n t he figure, t he business designers have recognized a business unit , it s recept ion, and it s depart m ent s as significant organizat ions. Purchase- order docum ent s and personnel and product inform at ion sheet s have been det erm ined as significant resources. Last ly, t he fulfillm ent process has been ident ified as a significant process in t he operat ion of t he business. The act of represent ing t he business OPRs alone oft en reveals im m ediat e possibilit ies for im provem ent . When carried out in t he cont ext of an overall I T archit ect ure, t he t ask of business m odeling is an invest m ent in t he successive im provem ent of t he ent ire business operat ion. These im provem ent s m ay be t he result of bet t er aut om at ion of t he business using inform at ion t echnology. However, im m ediat e, non- I T- relat ed operat ional im provem ent s oft en out num ber t he I T- relat ed im provem ent s in t he init ial st ages of business m odeling. The reasons for t his are explained in Taylor ( 1995) . I n addit ion t o defining t he t hree int uit ive OPR business abst ract ions, t he m odeling st yle also can provide inform at ion on how t hese abst ract ions are relat ed. Such predefined t ypes of relat ionships help creat e m ore uniform m odels. More im port ant , t hey are in t he int erest of const ruct ive foresight down t he developm ent channel. They enable effect ive preparat ion downst ream in t he developm ent process w it hout const raining t he expressiveness of a business m odel. This is analogous t o t raffic rules st at ing t hat you m ay drive anywhere you want as long as you drive on t he right side of t he road. This sim ple const raint in t he way we drive enables t he ent ire signage and signaling of roads t o be prepared effect ively, once and for all, wit hout having t o ask every driver what side of t he road he or she int ends t o drive on. [ 8] I t also sim plifies t he rules and signaling at int ersect ions, m aking t hem easy t o learn and uniform ly enforceable. Wit hout t his const ruct ive foresight , a driver would never know what t he int ent ion of anot her driver is at a crossroad, and t he definit ion of st andard signaling ( t he aut om at ion and t he t ools) w ould be im possible. Just as t he clear rules of t he road significant ly reduce t he risk of driving, t he const rict ive foresight of t he m odeling st yle reduces developm ent risks and enables, for exam ple, m ore effect ive securit y m echanism s. The days of arbit rary rules of t he road are gone forever. By t he sam e t oken, t he days of arbit rary obj ect m odels as t he default approach are passé in t he Convergent Archit ect ure.

The OPR business abst ract ions and t heir relat ionships form a pat t ern, as shown in Figure 4.15. To achieve convergence, t his t op- level pat t ern visibly evolves t o ot her, m ore det ailed pat t erns t hroughout t he various levels of refinem ent , from t he business m odel t o various I T represent at ions t o t he final running syst em . The obj ect ive is t o preserve t he basic relat ionships shown in t he figure t hroughout all phases of syst em developm ent .

-113-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

Figur e 4 .1 5 : The basic OPR relat ionships and t he sem ant ics of OPRs. I n t he figure, t he base business obj ect leverages inherit ance in order t o sim plify t he m odel. All OPRs inherit it s com m on feat ures, including it s relat ionships: All OPRs are business obj ect s. The associat ion line and capt ion t o it s left indicat e t hat all business obj ect s are, by default , searchable and t raded via t heir designat ed owning organizat ion. The dot t ed line denot es t hat t his m echanism is possible and, in t he absence of overriding circum st ances, is t he default relat ionship. This m eans t hat all posit ions downst ream in t he archit ect ure provide feat ures enabling effect ive searchabilit y and t rading. However, t he precise m eaning of " I nt ernet searchable, t raded" is not defined by t he business m odel. I t is defined by t he t echnology proj ect ion chosen for a part icular inst ance of t he Convergent Archit ect ure. The business m odel and subsequent UML m odels only define how searchabilit y and t rading feat ures are configured, not t heir precise im plem ent at ion. The m odels are not sim ply a not at ional t ranslat ion or visualizat ion of a part icular im plem ent at ion. I nst ead, depending on t he t echnology proj ect ion, t hey m ay be m apped t o m any different im plem ent at ions. The archit ect ural I DE act ively support s t he t ask of configurat ion according t o t he const raint s of a specific t echnology proj ect ion. This well- defined relat ionship wit h t he t echnology proj ect ion downst ream in t he design flow is im port ant because, in order t o rem ain sim ple and com pat ible, m odels cannot arbit rarily define how such com plex m echanism s as searchabilt y and t rading will work, nor should t hey be am biguous about such business- relevant aspect s of a syst em . The relat ionships associat ed wit h t he organizat ion in t he figure show t hat organizat ions are m anagers of all OPRs and are t he cent ers for t rading and dispat ching t hese cont ained OPRs. All business obj ect s locat e OPRs and negot iat e t heir access and use via t he organizat ion. Thus, t he organizat ions are t he t op- level enforcers of securit y policy as well as t he principal qualit y of service ( QoS) query int erfaces by which pot ent ial users locat e t he OPRs best suit ed t o t heir needs. Aside from being a business obj ect , t he process has t he possibilit y ( denot ed by t he dot t ed line) t o m ore direct ly associat e it self wit h resources. This direct associat ion m eans t hat it m ay possess references t o specific resources over long periods of

-114-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

t im e. Such direct binding, like all ot her relat ionships in t he diagram , brings wit h it a cert ain set of t radeoffs downst ream in t he developm ent process. The archit ect ural st yle's preference for t he set of t radeoffs associat ed wit h t rading is expressed by t he presence of t rading as t he t op- level default , aut om at ically inherit ed from t he base business obj ect . However, t he fact t hat processes oft en require an explicit , direct associat ion is also recognized by t he st yle and indicat ed by t he pot ent ial t o overload t he business obj ect 's default wit h t he direct alt ernat ive—at a cost . Once again, t he precise t radeoff set associat ed w it h t he alt ernat ives can only be defined by t he select ed t echnology proj ect ion—m ore evidence of t he sensit ive relat ionship bet ween business design opt ions and syst em design realit y. Analogous t o a process, a resource also m ay have direct relat ionships wit h ot her resources. As all business obj ect s, a resource has a part icularly int im at e relat ionship w it h it s owning organizat ion. Once again, t he precise propert ies of t his relat ionship depend on t he t echnology proj ect ion. This focus on t he business perspect ive of t he OPRs in t his sect ion em phasizes t he relat ionship bet ween t he business, proj ect , and syst em design, t his t im e at t he level of business m odeling. Alas, not even t he business m odel is exem pt from t he designer's paradox. Even t he business designers m ust som ehow deal wit h engineering realit ies t o keep such realit ies from creeping up and, oft en, wreaking havoc on proj ect s down- st ream in t he developm ent effort . Experience show s t hat invest m ent s in m odels, business m odels or ot her m odels, t hat cannot be proj ect ed easily t o available t echnologies are at best dubious regarding t heir effect iveness and ret urns. One st ep t oward avoiding such dubious invest m ent s is not t o leave t he designer in t he dark concerning t he relevance of const raint s t hat await him or her downst ream . Reform ulat ing t his from t he perspect ive of a proj ect m anager, m odelers, including business consult ant s, should no longer work in t he opt im ist ic bliss of zero const raint s unt il t he proj ect hit s t he wall of realit y down- st ream in t he developm ent flow. To avoid t his, t he realit ies of t he t echnology proj ect ion ( including t he program m ing and im plem ent at ion phases) m ust be propagat ed at t he appropriat e level of abst ract ion upst ream , producing a higher level of design sensit ivit y. This does not m ean t hat t he designs are any worse or any harder t o produce. I n fact , j ust t he opposit e is t he case: They are cleaner, sim pler, and m ore effect ive because t hey express t he business st rat egy, t he OPRs, using a m odeling st yle t hat underst ands how t he m odel should evolve, by hand or aut om at ically, and wit h higher qualit y int o t he next level of refinem ent . To com e back t o t he analogy: Who cares w het her we drive on t he right or t he left side of t he road? Sim ply by specifying t his inert driving const raint up front in t he design st ream , we im prove t he qualit y and effect iveness of t he ent ire t ransport at ion syst em downst ream . Moreover, such design sensit ivit y does not m ean t hat t he business and syst em design are inext ricably coupled. To t he cont rary, alt hough som e level of coupling m ust exist in t he int erest of engineering realit y, unnecessary coupling is avoided by explicit ly dealing wit h t he exist ence of t hese realit ies in t he archit ect ural st yle—t he designer's paradox. The OPR Conve r ge nt Com pone n t s This sect ion com plem ent s t he preceding sect ion by focusing on how a business m odel is t ransposed via com ponent s int o an I T syst em . Figure 4.16 illust rat es t he convergent m apping of t he business design int o I T com ponent s. To t he left , we see t he m odel from t he business perspect ive, as developed using t he reduced set of

-115-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

abst ract ions: organizat ions, processes, and resources. The right side of t he diagram shows t he sam e reduced abst ract ion set from t he soft ware perspect ive. This alignm ent of t he business m odel wit h t he com ponent m odel is a high- priorit y goal in t he Convergent Archit ect ure.

Figur e 4 .1 6 : The convergent OPR com ponent s. I n t he soft ware perspect ive, we see t hat t he com ponent s add t he I T dim ension aspect s while visibly preserving t he feat ures of t he business dim ension in t he business com ponent s. The figure also shows t he relat ionship bet ween ut ilit y com ponent s ( defined lat er) and t he business- com ponent hierarchy. The ut ilit y com ponent does not inherit from t he base business com ponent because it is, in effect , t he ant it hesis of t he business com ponent : By definit ion, it has no business relevance.

The business com ponent is shown as t he first com ponent wit h business relevance and, as such, w it h a visible business dim ension. I t s dot t ed out line suggest s t hat it t oo is abst ract and serves prim arily t o fact or out com m on charact erist ics of t he OPRs. The visibilit y of t he business dim ensions in t he OPRs exist s t o preserve convergence, em phasizing t hat t he designer and t ools are t o m ap t he OPR business obj ect m odel at t he left of t he figure t o t he convergent com ponent s at t he right of t he figure. Alone, t he visibilit y, t ract abilit y, and reversibilit y of t his convergent m apping sim plify bot h t echnical and concept ual aspect s of a design. [ 9] The process, pat t erns, t echniques, and t ools for convergent m apping are covered in Chapt ers 6 and 7 in conj unct ion wit h t heir concret e applicat ion using t he archit ect ural I DE. From t he perspect ive of t he convergent com ponent m et am odel it self, t he UML m odeling and t echnology proj ect ion of t he OPRs rem ains t o be discussed.

UM L M ode lin g a n d Te ch n ology Pr oj e ct ion of OPRs St art ing from t he business m odel, it is im port ant t o keep t he OPRs clearly visible t hrough t he UML m odels and int o t he runt im e environm ent . The m odeling st yle, part of t he TPC, defines how t he quadrant s of t he OPRs are m odeled using st andard UML for a given t echnology proj ect ion such as J2EE/ EJB. Maint aining t he

-116-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

business and I T dim ensions as separat e ent it ies t hroughout t he design flow is part icularly valuable. First , it perm it s t he workers on a t eam t o be m ore appropriat ely allocat ed: Business logic developers can focus on t he clearly visible business dim ension. I n addit ion, due t o t he m odel- level support of t hese dim ensions, t he I T dim ension can be generat ed aut om at ically from t he m odel for a part icular t echnology proj ect ion. The archit ect ural I DE also can bet t er support t he very different life cycles of t he t wo dim ensions. The business dim ension, which cont ains t he m aj orit y of an organizat ion's business logic, can be m odeled, versioned, docum ent ed, and st ored as separat ely m anaged ent it ies. Even t he generat ed build and deploym ent infrast ruct ure ( t hat is, direct ory st ruct ures, files, and build script s) and t he result ing runt im e syst em ( t hat is, com ponent s, classes, and obj ect s) can separat e t he t w o life cycles. For exam ple, a J2EE t echnology proj ect ion generat es t he business dim ension int o a com plet ely different direct ory st ruct ure, separat e from one or m ore I T dim ensions. This single business dim ension can t hen be used t oget her wit h several different I T dim ensions. Thus, different applicat ion servers can be deployed or t est ed in parallel wit h t he sam e business dim ension, or a version upgrade from one server infrast ruct ure t o anot her can be handled sim ply by regenerat ing t he I T dim ension from t he m odel. These im provem ent s by t hem selves result in significant ly higher developm ent qualit y in less t im e wit h fewer resources.

Developing an effect ive t echnology proj ect ion for t he OPRs is far from t rivial. This is not due t o any inherent problem s in t he OPR st ruct ures or sem ant ics; rat her, it is caused by t he fact t hat t he business dim ensions of t he OPRs are, by design ( see Figure 4.15) , closer t o t he business t han t hey are t o current ly available t echnology. The challenge of t he specific t echnology proj ect ion is t hen t o place as few const raint s on t he business dim ension of t he OPRs as possible while st ill support ing a robust , assist ed, or aut om at ic proj ect ion t o available t echnology. This t urns out t o be a real challenge because t he OPRs, as sim ple as t hey appear, push t he lim it s of even t he best t echnologies. I n addit ion, our basic principles require t hat t he t echnology proj ect ion avoids coupling wit h short - lived, propriet ary im plem ent at ions, which, quit e correct ly, narrow t he opt ions available t o t he designer of a t echnology proj ect ion. To dat e, essent ially t wo approaches have been t aken t o t echnology proj ect ion. These approaches affect t o som e ext ent t he t echnology proj ect ion of all t he convergent com ponent s. However, t he OPRs, as t he core business com ponent s, define t he driving t radeoff set . These approaches represent t wo ends of a spect rum of reasonable t radeoff set s. Different I T organizat ions invariably select different posit ions wit hin t his spect rum . The first approach is t o com plem ent available t echnology by im plem ent ing high- level feat ures of OPRs. This approach enables m ore pow erful OPRs from t he business design perspect ive at t he cost of requiring som e propriet ary ext ensions t o st andards- based t echnologies. The ext ent of t hese im provem ent s current ly st rains our requirem ent t hat we avoid coupling wit h propriet ary t echnology. The second approach, and t he one t aken by t he default J2EE t echnology proj ect ion described in t his book, represent s t he ot her end of t he t radeoff spect rum . I t m aps t he OPRs t o t he robust feat ures of available st andards- based t echnology, such as a J2EE server, and avoids any significant ext ensions. Nevert heless, we do allow it t o sm oot h out t he rough edges of a part icular J2EE server wit hout drift ing from t he st andard. This approach t urns t he t radeoff set around: The OPRs are no longer in t he driver's seat . I nst ead of placing hard requirem ent s on t he infrast ruct ure, t he OPRs willingly subm it t o it s lim it at ions.

-117-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

I n t his approach, t he OPRs are m ore lim it ed in t heir capabilit ies, whereas t he t echnology proj ect ion is bet t er aligned wit h m ainst ream t echnology, m ore port able, and easier t o com m unicat e. Any point in t his t radeoff spect rum is equally well support ed by t he Convergent Archit ect ure as long as t he point is specifically select ed. A closer look at t he t wo approaches, t he t w o ends of t he spect rum , shows how t his works. The first approach has been around longer t han t he second approach. This is because com ponent st andards and st andards- based infrast ruct ures have only recent ly reached a level where t hey can reasonably support realit y- scale syst em s. Before t he advent of J2EE/ EJB, t he first approach proj ect ed organizat ions t o CORBA- t rader- com pliant com ponent s in CORBA- cent ric infrast ruct ures. Process and resource com ponent s were t he t raded CORBA obj ect s. Process com ponent s leveraged propriet ary workflow t echnology in order t o reasonably support UML process m odels. Oddly, de fact o st andards for m odeling process workflow in UML were available before any im plem ent at ions of t hese de fact o st andards. Thus, t he TPC and t he archit ect ural I DE could support st andards- based UML m odeling for processes, such as t he m et hod of event - driven process chains ( EPCs) ( Aalst 1998) , while having t o proj ect t hese UML m odels t o propriet ary im plem ent at ions. Using current J2EE/ EJB st andards and t echnology for t he first approach is sim ilar. I n t hese const ellat ions, organizat ions are m odeled and proj ect ed t o EJB com ponent s t hat have been ext ended t o use t he EJB query m echanism s in t he form of a com ponent t rader. CORBA- t rader concept s oft en are leveraged here. Alt ernat ively, an ent ire EJB cont ainer represent s a single organizat ion. The EJB m odeling st yle for organizat ions is explicit ly ext ended t o expose relevant t rader feat ures in UML, and t he t echnology proj ect ion is ext ended t o m ap t hese feat ures t o t he part icular J2EE im plem ent at ion. Sim ilar t o t he CORBA- cent ric approach earlier, processes are m odeled using a process- m odeling ext ension in t he UML m odeling st yle. These m odels are t hen proj ect ed t o propriet ary, organizat ionspecific ext ensions t o EJB or, preferably, t o purchased workflow engines. I n t he first approach, it is im port ant t o not e t hat any ext ensions m ay be generat ed t o several different t echnologies. However, t he effort required t o m aint ain t he t echnology proj ect ion for each plat form m ay be significant —an im port ant considerat ion in t he t radeoff set .

I n t he second approach, t he I T organizat ion decides t hat t he advant ages due t o st andards and m ainst ream alignm ent out weigh t he advant ages of high- end OPR sem ant ics. I n t his approach, t he capabilit ies of t he OPRs subm it t o t he const raint s of available t echnologies. Alt hough st ill valuable, t he OPRs are not as powerful as we would wish. Over t im e, developers can increase t heir power based on im provem ent s in st andards and m ainst ream t echnology. This is a slow er increm ent al approach, but it is low risk and low resist ance from t he perspect ive of t he I T organizat ion. On t he ot her side of t he coin are t he com prom ises t hat m ust be m ade in t he OPR designs. Organizat ions are designed in UML as EJBs t hat are preconfigured t o use t he best available query feat ures and associat ion m anagem ent feat ures, as long as t hese feat ures rem ain close t o t he EJB st andard. The t echnology proj ect ion t hen select s and t unes t he best configurat ion of t hese feat ures for t he part icular im plem ent at ion t echnology. I n ot her words, t here is no st andard way t o use t he im plem ent at ion of a st andard. There are several ways t o skin a cat , and a good t echnology proj ect ion, while rem aining close t o t he st andard,

-118-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

different iat es it self from run- of- t he- m ill code generat ors by providing expert t uning of t he feat ures of a part icular J2EE/ EJB im plem ent at ion. Such t uning is com plex but im port ant because t he various J2EE/ EJB applicat ion servers do differ significant ly in t he im plem ent at ion and t uning of t heir st andard- conform J2EE feat ures. I n t he second approach, t he sam e basic rules apply t o processes and resources. Processes are, of course, m uch m ore challenging t o m ap t han resources. I n fact , processes are t he place where t he m ost com prom ises m ust be m ade when using current J2EE/ EJB t echnologies. Several m aj or problem s can occur when im plem ent ing EPCs ( discussed previously) using current st at e- of- t he- art st andards and t heir im plem ent at ions. These problem s range from coordinat ing concurrency in t he presence of isolat ed t ransact ions ( t he so- called lost updat e problem ) t o t he severe lim it at ions on m ult it hreading t hat arise as a side effect of t ransact ional const raint s in t he EJB st andard. The list of problem s here is long and com plex, but t he bot t om line is t hat wit hout propriet ary ext ensions, proj ect ing processes m odeled along t he lines of EPC is out of t he quest ion. This is im proving, but t he current ly available t echnology j ust does not m ake it possible using st andardcom pliant feat ures. I nst ead, t he m odeling st yle in t he second approach requires process m odels t o be sim pler. Current ly, t his t ranslat es t o som e rest raint s in t he concurrency and asynchronous behavior of processes. Since t he UML m odeling st yle is explicit as t o it s capabilit ies, t he archit ect ural I DE can st ill check whet her a process in t he UML m odel com plies t o t he specific const raint s of a proj ect ion or not . The advant age of t his approach is found in t he long- t erm perspect ive. When st andards and t heir im plem ent at ions im prove, t he m odeling st yle and t he t echnology proj ect ions can cash in im m ediat ely on t hese im provem ent s. This is so because t hey have not deviat ed previously from t he m ainst ream flow. The rest raint and resist ance t o t he t em pt at ion of propriet ary feat ures can result in significant ret urns in t he long run. The only prerequisit e t o t his payoff is a clear, consist ent pat h, a consist ent archit ect ural st yle. [ 7]

Obj ect orient at ion adds t hree powerful m odeling t ools t o t radit ional procedural represent at ions. One of t hese t ools is t ype abst ract ion, also known as inherit ance. The ot her t wo are class- level dat a abst ract ion ( encapsulat ion) and funct ion abst ract ion ( polym orphism ) . See Taylor ( 1997) for a pragm at ic int roduct ion t o t hese concept s.

[ 8]

Anot her well- known st yle defines driving on t he left side of t he road as it s st andard.

[ 9]

Wit h respect t o current OMG/ MDA concept s, t he business com ponent s begin wit h a core m odel at t he level of a responsibilit y- driven design at t he CRC business m odel level and evolve along a st ruct ured pat h, via m apping pat t erns, int o UML along t he course of convergent m odel refinem ent ( see Chapt er 6) .

Ut ilit y Com pon e n t s Ut ilit y com ponent s, short for t echnical ut ilit y com ponent s, are convergent com ponent s wit hout any business- dom ain relevance. They are not ( do not inherit from ) business com ponent s and as such do not possess any predefined business behavior or relat ionships. Sim ilar t o accessors, ut ilit y com ponent s encapsulat e ext ernal t echnology t o explicit ly ensure t he int egrit y of t he archit ect ure. I n cont rast t o accessors, t he t echnologies encapsulat ed by ut ilit y com ponent s are

-119-

Convergent Architecture

Chapter 4: The Convergent Component Metamodel

coinst alled as part of t he convergent syst em : They are eit her physically part of an assem bly, t hat is, inst alled as part of t he assem bly, or t hey are part of t he prerequisit e inst allat ion plat form required by t he assem bly. Ut ilit y com ponent s are used t o im plem ent any purely t echnical aspect s of a convergent syst em and t o abst ract t he ot her convergent com ponent s from fast changing aspect s of im plem ent at ion t echnologies. Thus, as shown in several of t he preceding figures, a ut ilit y com ponent does not norm ally im plem ent a business dim ension; it s only act ive dim ension is it s I T dim ension. Typical exam ples of ut ilit y com ponent s include logging facilit ies, adm inist rat ive or m onit oring facilit ies, securit y servers, key servers, and configurat ion servers used uniform ly by all convergent com ponent s.

Su m m a r y The convergent com ponent m et am odel present ed in t his chapt er plays a m aj or role in t he archit ect ural st yle. I t defines convergent com ponent s as a vehicle t o assist business designers and developers along t he pat h from high- level business m odeling t o effect ive design represent at ions t o running I T syst em s. The m et am odel first defines how t he concept s of convergent engineering, t he UML st andard, and com ponent design st andards such as J2EE/ EJB are com bined t o m odel and im plem ent convergent com ponent s. I t part it ions convergent com ponent s int o archit ect ural layers and specifies how each of t hese layers cont ribut es t o t he m odel- cent ric developm ent of a convergent syst em . The responsibilit ies, relat ionships, and st ruct ure of each convergent com ponent are described in conj unct ion wit h it s posit ioning as part of a UML m odeling st yle. I n each case, t he im port ant propert ies of t he t echnology proj ect ion are discussed as well as t he fact ors realist ically influencing proj ect ion t o current and fut ure t echnologies. I n t he following chapt ers, convergent com ponent s and t he associat ed concept s seen in t his chapt er will be used t o st ream line t he I T organizat ion, t he developm ent process, and t he archit ect ural I DE and t o increase t he effect iveness of each one of t hese cog- wheels in t he clockw ork of holist ic archit ect ure.

-120-

Convergent Architecture

Chapter 5: The IT-Organization Model

Ch a pt e r 5 : Th e I T- Or ga n iza t ion M ode l— Th e bu sin e ss of bu ildin g I T syst e m s Ove r vie w The developm ent m odel of t he Convergent Archit ect ure is com prised of t hree subdivisions. The second of t hese is t he I T- organizat ion m odel, which is covered in t his chapt er.

TE

AM FL Y

The inform at ion t echnology ( I T) organizat ion is one of t he m ost significant organizat ions of any m odern business. I t s services are crit ical t o t he success of t he business as a whole because t he syst em s it produces are t he lifeblood of ot her organizat ions in t he business. This m eans t hat t he I T organizat ion is essent ially responsible for represent ing and opt im izing t he operat ional aspect s of ot her business organizat ions. We saw in previous chapt ers t hat t he process of building t he I T syst em s is synonym ous wit h t he process of underst anding and opt im izing t he business. The business, however, consist s of m any various organizat ions, each st riving t o im prove t he business as a whole and each crucially dependent on I T syst em s t o achieve t his goal. The I T organizat ion is t he only organizat ion in a posit ion t o facilit at e cross- funct ional opt im izat ion across all ot her organizat ions and t o help t hese organizat ions represent , opt im ize, and support t heir st rat egies as part of a holist ic whole. However, t o be successful in t his cent ral role, t he I T organizat ion m ust first win t he confidence of ot her business organizat ions. I t m ust it self lead t he way as t he role m odel of effect ive design and I T support . I f it did not , every effort t o help ot her organizat ions opt im ize t heir work would be regarded, quit e correct ly, as pret ent ious. An organizat ion responsible for business opt im izat ion m ust it self pract ice what it preaches. This professionalism is im port ant not only from t he perspect ive of credibilit y, but also from t he perspect ive of being effect ive in t he business of building I T syst em s. This is why t he Convergent Archit ect ure posit ions t he I T organizat ion first and forem ost as t he business organizat ion t hat m ust get it s respect ive house in order before at t em pt ing t o help ot hers im prove t heirs. From t his perspect ive, t he t ask of t he archit ect ural st yle is t o define what it s house should look like and how it should be run in order t o opt im ally produce syst em s according t o t he st yle. The following sect ions provide a st ruct ured represent at ion, or m odel, of t he I T organizat ion as it should operat e t o best support t he ot her feat ures of t he archit ect ural st yle. When creat ing an inst ance of t he Convergent Archit ect ure, t his m odel is used as t he roadm ap t o set up a new I T organizat ion. I t is also em ployed for t he evolut ion of exist ing organizat ions. The result is a sit uat ion- specific represent at ion, or m odel, of an I T organizat ion. As explained in Chapt er 2, t he Convergent Archit ect ure " uses what it sells." This m eans t hat t he I T organizat ion is m odeled using t he sam e concept s t he Convergent Archit ect ure uses t o m odel any business organizat ion. These are t he business abst ract ions: organizat ions, processes, and resources. The I T- organizat ion m odel focuses on organizat ional st ruct ure and t he resources t hat populat e t his st ruct ure. These are t he resources relevant t o syst em developm ent , such as workers, developm ent t eam s, and soft ware. When referring t o an I T organizat ion as defined by t he Convergent Archit ect ure, I use t he spelling I T organizat ion. The I T organizat ion is where bot h resources and processes live. I t defines t he st ruct ure in which t he ent ire developm ent process operat es. I t is where

-121-

Team-Fly®

Convergent Architecture

Chapter 5: The IT-Organization Model

t he com ponent s of t he developm ent process find t he resources t hey require and deliver t he resources t hey produce. I t adds an aspect of calm ing cont inuit y and order, which effect ively direct s t he ever- changing landscape of developm ent proj ect s. Thus, t he I T organizat ion, as covered in t his chapt er, is t he prerequisit e foundat ion on which t he developm ent process is built . The corresponding process m odel—t he developm ent process m odel—present ed in t he following chapt er is based on t his foundat ion.

Before get t ing int o det ails, let 's t urn our focus t o t he I T organizat ion and it s posit ioning wit hin a business organizat ion, as illust rat ed in Figure 5.1. I n t his and subsequent figures, organizat ions are represent ed as rounded rect angles in accordance w it h convergent engineering. Figure 5.1 depict s t he I T organizat ion as an int egral part of t he overall business. The out erm ost organizat ion represent s t he t op- level business organizat ion. The organizat ions t o t he right in t he diagram ( t hat is, t he sales and finance and adm inist rat ion organizat ions) are t ypical exam ples of ot her core business organizat ions. All t he organizat ions out side t he I T organizat ion are t he organizat ions it support s. They are it s client s or it s cust om ers. The figure also shows t he int ernal st ruct ure of t he I T organizat ion. I t is com prised of it s int ernal or suborganizat ions. Each of t he I T organizat ions is sum m arized here: ƒ

ƒ

ƒ

ƒ

ƒ

-122-

I T or ga niz a t ion. This is concerned prim arily wit h proj ect design as well as t he environm ent and m echanism s required t o effect ively coordinat e m anifold I T- relat ed proj ect s. I t set s up and m anages t he following four int ernal organizat ions and represent s t heir cum ulat ive responsibilit y as t he int erface t o ext ernal or client organizat ions. Ar chit e ct ur e or ga niz a t ion. This is responsible for defining and m aint aining t he Convergent Archit ect ure and ensuring it s proper use. I t also has t echnical, proj ect m anagem ent , and m ent oring responsibilit ies focused on achieving t he high ret urns of professional I T archit ect ure across all organizat ions. I T- suppor t or ga niz a t ion. This is responsible for crit ical support services shared by t he ot her I T organizat ions, including all soft ware developm ent proj ect s. I t can be seen as t he operat ional syst em s organizat ion support ing t he business of I T developm ent . The I T- support organizat ion is com prised of sub- organizat ions for change and configurat ion m anagem ent , base infrast ruct ure adm inist rat ion, proj ect inform at ion m anagem ent , and t est cent er m anagem ent . Syst e m - de ve lopm e nt or ga niza t ion. This houses and m anages t he syst em - developm ent t eam s. I t coordinat es individual soft ware proj ect s and t he skills pool of developers w orking in t hese proj ect s. I t also defines t he goals and guidelines for a successful soft ware developm ent proj ect , as well as t he st ruct ure, roles, and responsibilit ies for a successful soft ware developm ent t eam , t he so- called canonical developm ent t eam . Ope r a t iona l- syst e m s or ga niza t ion. This is t he operat ional runt im e organizat ion responsible for deploying syst em s and m aint aining t heir product ion use by ot her business organizat ions. The operat ionalsyst em s organizat ion is com prised of suborganizat ions for soft ware deploym ent , user support , and base infrast ruct ure adm inist rat ion.

Convergent Architecture

Chapter 5: The IT-Organization Model

Figur e 5 .1 : The I T organizat ion in a business cont ext . The following sect ions cover each of t hese organizat ions in m ore det ail.

Fe a t u r e s Com m on t o All I T Or ga n iz a t ion s I n accordance wit h t he principles of t he archit ect ural m et am odel, we use t he t echniques of responsibilit y- driven design and obj ect - orient ed t echnology t o describe t he I T organizat ions. This begins by defining t he feat ures com m on t o all I T organizat ions and out lining t he st ruct ure and t erm inology used t o describe all I T organizat ions. Readers fam iliar wit h obj ect - orient ed t echnology would int uit ively call t his t he base I T organizat ion. The charact erist ics of t he organizat ion, process, and resource abst ract ions ( OPRs) , com m on t o bot h t he I T- organizat ion m odel and it s relat ed developm ent process m odel, are covered in t he rem ainder of t his sect ion. OPRs are design pat t erns int roduced by Dr. David A. Taylor in his book on convergent engineering ( Taylor 1995) . The m odels of t he Convergent Archit ect ure leverage and build on t hese pat t erns; however, Dr. Taylor's book should be consult ed for t he rat ionale and det ail behind t hese pat t erns. To assist readers who are not yet very fam iliar wit h convergent engineering, t he necessary OPR fundam ent als are reviewed here in conj unct ion wit h descript ions of how t hey are applied specifically in t he I T organizat ion. You m ay w ant t o refer t o Figure 3.4 while reading t he follow ing descript ions. Or ga niza t ion, Pr oce ss, a nd Re sour ce Abst r a ct ions ( OPRs) OPRs are unit s of well- defined responsibilit y. Such responsibilit ies also include t he relat ionships OPRs m aint ain wit h each ot her, as described here. I n general, OPRs are fract al in bot h st ruct ure and behavior. This m eans t hat t hey m ay be nest ed t o any level, wit h each level m aint aining com pat ible behavior. This applies t o all subt ypes of OPRs. For exam ple, as you will see, t he I T organizat ion cont ains an archit ect ure organizat ion. They are bot h organizat ions, and as such, t hey inherit t he com pat ible st ruct ures and behavior of an organizat ion. The archit ect ure organizat ion m ay cont ain ot her organizat ions. Such nest ing m ay go on indefinit ely. This const it ut es what is known in convergent engineering as a fract al st ruct ure because no m at t er how far you drill down int o t he det ails of t he st ruct ure of t he I T organizat ion, you st ill see t he fam iliar form s and behavior of organizat ions. Persons fam iliar wit h obj ect - orient ed t echnology recognize t hat t he power of

-123-

Convergent Architecture

Chapter 5: The IT-Organization Model

fract al st ruct ures and fract al behavior is t he result of applying t he t hree pillars of obj ect - orient ed t echnology: dat a abst ract ion ( encapsulat ion) , t ype abst ract ion ( inherit ance) , and funct ion abst ract ion ( polym orphism ) . However, you do not have t o be an expert in obj ect - orient ed t echnology t o underst and and apply t hese powerful concept s t o sim plify t he I T organizat ion. Or ga n iza t ion s Organizat ions m anage processes, resources, and ot her organizat ions. They group people and ot her resources charged wit h carrying out specific business processes. An organizat ion coordinat es and represent s t he cum ulat ive responsibilit ies of it s cont ained OPRs. For exam ple, j ust as in " real" business organizat ions, an organizat ion priorit izes t he access and use of it s OPRs, im plem ent s securit y m easures, and t racks t heir use. I n t he I T- organizat ion m odel present ed here, organizat ions are defined according t o t heir responsibilit ies, t heir workers ( see " Resources" ) , and t he responsibilit ies of t hese workers. Pr oce sse s Processes are goal- direct ed sequences of act ivit ies or t asks t hat are enabled by resources. They access or consum e resources in order t o enhance or produce ot her ( hopefully m ore valuable) resources. For exam ple, a process m ay consum e a person's t im e t o produce a docum ent describing anot her new process. The docum ent is a resource t hat has been produced by t he process. Since processes m ay be nest ed t o any level of granularit y ( all OPRs are fract al) , t hey can represent high- level workflows as well as highly granular t asks. I n t he I T- organizat ion m odel, we dist inguish t w o t ypes of processes t o represent t he granularit ies we require. The granularit ies and nam es used for t hese processes are in full alignm ent wit h t he rat ional unified process. They are ƒ ƒ

W or k flow s. Long- t erm , ident ifiable groupings of logically relat ed act ivit ies. Act ivit ie s. I dent ifiable groups of logically relat ed t asks. Tasks are m easurable, at om ic unit s of w ork t hat usually are associat ed wit h a specific t echnique. They are t he sm allest unit of planned and assigned w ork in an organizat ion.

Re sour ce s Resources are int elligent unit s of value, cost , and act ion in an organizat ion. They represent sources of business value, work, and inform at ion used by ot her OPRs. Three t ypes of resources of part icular relevance exist in t he I T organizat ion: ƒ

-124-

W or k e r s. Hum ans are im port ant resources for an organizat ion, of course. Moreover, t he roles a person can fulfill are resources. I n t he I Torganizat ion m odel, t he relat ionship bet ween a hum an resource and a role fulfilled by a hum an is known as a worker. This corresponds t o t he t erm worker as used in t he rat ional unified process. A single person m ay have m any worker relat ionships. For exam ple, if Susan possesses t he skills t o fulfill t he role of com ponent developer or lead developer in a proj ect , she m ay be assigned as t he worker fulfilling bot h t hese roles.

Convergent Architecture

ƒ

ƒ

Chapter 5: The IT-Organization Model

This explicit separat ion of hum ans from t heir pot ent ial roles, as well as t he represent at ion of t he worker relat ionship bet ween t hese t wo, is anot her im port ant pat t ern in convergent engineering. As part of t heir responsibilit ies, workers coordinat e all ot her, inanim at e resources w it hin an organizat ion such as m achinery, m oney, t im e, and so on. Ar t ifa ct s a nd cha nge se t s. Also in line wit h t he Rat ional Unified Process ( RUP) , we denot e t he resources produced or used by t he I T organizat ion in t he cont ext of syst em developm ent as art ifact s. Art ifact s m ay be versioned alone or grouped int o versioned set s. Such versioned groups are known as change set s. A change set m ay cont ain one or m ore art ifact s. Change set s are m anaged using a configurat ion and change m anagem ent ( CCM) syst em , as described lat er. Thus, for our purposes, change set and art ifact are synonym s, except t hat a change set m ay cont ain several nam ed art ifact s. We use t he t erm change set when we speak of t he art ifact s grouped by t he change set . I n t he I T- organizat ion m odel, t he art ifact s and t he change set s t o w hich t hey belong are present ed t oget her wit h t heir respect ive m anagers. How and when t hese art ifact s are creat ed, and by whom , is t he t opic of t he process m odel. Te ch nologie s ( r e fe r e nce t e ch nologie s) . The I T organizat ion pract ices t he sam e rules of t echnology m anagem ent t hat it applies t o ot her organizat ions of a business. Just as t he I T organizat ion rigorously plans and opt im izes t he applicat ion of t echnologies in ot her business organizat ions, t he coordinat ed and planned use of t echnology is im port ant for it s ow n effect ive operat ion. Technologies developed out side t he I T organizat ion have been conceived in t heir own t echnological scope, oblivious of t he concept s unifying a part icular archit ect ural st yle. This requires t hat cert ain crit ical t echnologies be posit ioned properly w it hin t he archit ect ural st yle t o avoid pollut ion of it s concept s. At t he sam e t im e, t he archit ect ure should leverage m odern t echnologies effect ively. To t his end, t he I T organizat ion recognizes ext ernally developed t echnologies as a special set of art ifact s. I t specifies t hose t echnologies used t o support highly specialized act ivit ies in t he I T organizat ion. I t does not specify a t echnology in cases where t he choice of t echnology is noncrit ical ( t angent ial) or noninvasive ( for exam ple, general office t ools) from t he perspect ive of t he archit ect ural st yle. I n addit ion, t he m anager of t he t echnology and it s int ended use in t he I T organizat ion are present ed. Nam ing specific t echnologies in crit ical areas helps an I T organizat ion get off t o a running st art . Clearly, t he t echnologies specified here are reference t echnologies because t hey m ay be som ewhat different in a part icular inst ance of t he Convergent Archit ect ure. Even so, it is easier t o get st art ed based on a concret e, t ried- and- t rue reference set . These t echnologies also will evolve wit h t im e, but t he t ypes of t echnologies used and t heir roles will rem ain st able. I n ot her words, t heir evolut ion will be st eady and clearly visible, not abrupt and obscure. As t im e goes by, t he experience of t he chief archit ect , in accordance wit h t his worker's responsibilit ies, cert ainly will suffice t o m ake t he appropriat e adapt at ions.

Using t his new OPR t erm inology, we can now say m ore precisely t hat t he I Torganizat ion m odel covered in t his chapt er focuses on t he I T organizat ion, it s cont ained organizat ions, and t he art ifact s ( resources) associat ed wit h t he

-125-

Convergent Architecture

Chapter 5: The IT-Organization Model

organizat ion. The developm ent process m odel covered in t he next chapt er t hen explains how act ivit ies ( processes) operat e in conj unct ion wit h t hese organizat ions and how t he act ivit ies use, produce, and m anage art ifact s. Worker roles are always defined wit hin t he cont ext of a part icular organizat ion. Thus, t he sum of t he worker roles in t he organizat ion essent ially defines t he responsibilit ies of t he organizat ion. I n addit ion, a worker fulfilling a part icular role is always working in t he cont ext of a specific organizat ion, not j ust a process. This is im port ant for t wo reasons. First , skills and roles should be grouped t o achieve synergies. These groups are t he organizat ions. Second, it is im port ant t o know which organizat ion is responsible for coordinat ing t he person fulfilling t he role—t he worker. I f a person fulfills roles in t w o different organizat ions, t hen, by default , t his person is m anaged on t he level of t he next higher organizat ion. This is necessary because only t he next higher organizat ion possesses an undisput able aut horit y t o coordinat e t he t im e allocat ed by t his person t o each of t he suborganizat ions. A det ailed descript ion of t he organizat ional st ruct ure begins by present ing t he roles and responsibilit ies com m on t o all I T organizat ions. Alt hough som e of t hese roles and responsibilit ies m ay appear obvious t o t he seasoned developer or proj ect m anager, experience show s t hat m any of t hem are not being defined and fulfilled effect ively in proj ect s. I ronically, t he largest proj ect s are oft en t he worst offenders. A realist ic proj ect m anager or ot her st akeholder in a soft ware proj ect will not perm it him self or herself t o get pulled int o a sit uat ion where t hese roles are being ignored. Each one of t hem is crit ical t o t he proj ect 's success. I gnoring any of t hem increases t he proj ect 's risk.

W or k e r Role s a n d Re spon sibilit ie s The roles and responsibilit ies of workers com m on t o all organizat ions are as follows: ƒ

-126-

Or ga n iza t ion m a na ge r . The organizat ion m anager is responsible for t he overall fulfillm ent of an organizat ion's responsibilit ies. The t erm m anager sim ply com m unicat es a higher level of responsibilit y and com m ensurat e aut horit y. [ 1] Not only do m anagers coordinat e in t he cont ext of t he Convergent Archit ect ure, t hey also m ay do hands- on cont ent w ork, depending on t he organizat ion, and t hey m ay engage st aff t o help t hem carry out t heir responsibilit ies. Above all, t he organizat ion m anager focuses on opt im izing invest m ent s wit h respect t o t he overall business priorit ies as agreed w it h t he m anagem ent of higher- level organizat ions. More im port ant , t he organizat ion m anager is t he safet y net , picking up all t he ad- hoc t asks and responsibilit ies t hat w ere not predefined explicit ly but are deem ed t o fall logically in t he organizat ion. I n part icular, t he organizat ion m anager o I s t he highest escalat ion point and t op- level decision m aker in t he organizat ion. o I s t he principal com m unicat ions and m anagem ent int erface t o ext ernal organizat ions—t he client s. This includes const ruct ive feedback regarding designs and procedures in t he form of requirem ent s channeled t o t he requirem ent s m anager ( defined lat er) .

Convergent Architecture

o

o

o o

o

ƒ

ƒ

ƒ

ƒ

-127-

Chapter 5: The IT-Organization Model

Defines, plans, t racks, and opt im izes proj ect s in t he int erest of client organizat ions. This includes coordinat ing and priorit izing requirem ent s placed on t he organizat ion by ot hers. I s a m em ber of t he st eering t eam ( discussed lat er) in t he next higher organizat ion and convenes and leads t he st eering t eam m eet ings in his or her own organizat ion. Plans and coordinat es t he suborganizat ions and is fully responsible for t hem . Perform s funct ional m anagem ent of t he personnel and facilit ies of t he organizat ion. This includes procurem ent and adm inist rat ion of all resources required by t he organizat ion. I s a Convergent Archit ect ure- specific inst ance of t he RUP worker: a proj ect reviewer prim arily from t he I Torganizat ion perspect ive. The proj ect reviewer from t he I T archit ect ure perspect ive is t he chief archit ect ( discussed lat er) .

Pr oj e ct m a na ge r . Analogous wit h t he organizat ion m anager but responsible for t he overall fulfillm ent of a defined proj ect 's responsibilit ies, t he proj ect m anager is t he m anager of a well- defined proj ect . Once t he organizat ion m anager has defined a proj ect , t he proj ect m anager runs t he proj ect from it s init ial planning t hrough t o t he final proj ect closure. He or she report s t o t he organizat ion m anager and m ay be asked t o part icipat e in st eering t eam m eet ings. Sponsor ing clie nt . The sponsoring client is a person or organizat ion ( ext ernal or int ernal) t hat sponsors a proj ect . The sponsoring client m ay be an ext ernal soft ware client or a represent at ive of an ent ire soft ware m arket ( for exam ple, a soft ware product m anager) . I n cases w here t he sponsoring client consist s of a group or consort ium , a client st eering t eam is defined t o provide an aut horit at ive, represent at ive body act ing in t he int erest of t he sponsoring client . The I T organizat ion m anager init iat es t he client st eering t eam , if required, and coordinat es it s int eract ion wit h t he rest of t he I T organizat ion. W or k flow ow ne r , a ct ivit y ow ne r , r e sour ce ow ne r . This worker t akes full responsibilit y for t he com plet ion of a nam ed workflow, act ivit y, or life cycle of a nam ed art ifact , respect ively. Each workflow, act ivit y, and resource has a single owner. St e e r ing t e a m . The st eering t eam is responsible for global ( horizont al) planning and opt im izat ion in organizat ions t hat cont ain m ult iple suborganizat ions. This includes t he ident ificat ion, boot st rapping, or m odificat ion of proj ect s, as well as handling escalat ion sit uat ions. The st eering t eam convenes at t he discret ion of t he organizat ion m anager. I t consist s of t he organizat ion m anagers of t he next lower level of organizat ions in t he hierarchy. For exam ple, t he st eering t eam of t he I T organizat ion consist s of t he organizat ion m anagers of t he archit ect ure, I T support , syst em developm ent , and operat ional- syst em s organizat ions. Each m em ber of t he st eering t eam represent s t he perspect ive of his or her m anaged organizat ion. This m ixt ure of com pet ence and responsibilit y ensures well- inform ed, rapid decisions as well as proact ive opt im izat ion across t he ent ire organizat ion. The I TOrganizat ion St eering Team

Convergent Architecture

o o

Chapter 5: The IT-Organization Model

Officially kicks off syst em developm ent proj ect s based on t he result s of t he proj ect init iat ion act ivit y. Term inat es syst em developm ent proj ect s based on it erat ion planning or review result s and in escalat ion sit uat ions.

These worker roles and responsibilit ies exist wit hin all I T organizat ions. They w ill not be list ed repeat edly in each of t he organizat ion- specific sect ions t o follow. However, any of t hese roles m ay be refined or specialized in t he cont ext of a part icular organizat ion. I n such cases, t he specialized aspect s of t he role are described and sim ply will refer t o t he com m on or base role it refines. [ 1]

Som e prefer t he t erm owner t o m anager because m anager has so m any different int erpret at ions. I have chosen t o use t he t erm m anager t o rem ain in line wit h t he RUP t erm inology, and t hen t o define what I m ean when I use t he word m anager.

Th e I T Or ga n iza t ion The t op- level I T organizat ion ( I T- O) , shown in Figure 5.2, is t he highest inst ance of decision and escalat ion concerning t he developm ent and operat ion of I T syst em s. I t s cust om ers are t he non- I T- focused organizat ions of t he business. I t s st eering t eam consist s of t he m anager of t he I T organizat ion and t he organizat ion m anagers of t he four organizat ions it cont ains, as shown in t he figure. This part icular st eering t eam is t he official int eract ion int erface t o all cust om ers and st akeholders out side t he I T organizat ion.

Figur e 5 .2 : The t op- level I T organizat ion. W or k e r Role s a nd Re sponsibilit ie s Worker roles and responsibilit ies in t he I T organizat ion include t he following:

-128-

Convergent Architecture

ƒ

ƒ

Chapter 5: The IT-Organization Model

I T- organizat ion m anager. I n addit ion t o responsibilit ies as an organizat ion m anager, t he m anager of t he I T organizat ion is specifically responsible for o Developing a sit uat ion- specific I T- organizat ion m odel and im plem ent at ion plan based on t he I T- organizat ion m odel. He or she carries out t he im plem ent at ion of t he I T organizat ion by kicking off workflow s ( see Chapt er 6) ; t hat is, he or she is t he t op- level operat ional owner of t he developm ent process. o I nit iat ing t he four int ernal organizat ions and t he t op- level st eering t eam . This begins wit h t he archit ect ure organizat ion, which t hen boot st raps t he Convergent Archit ect ure and part icipat es in t he det ailed planning and buildup of t he ot her suborganizat ions. o Procuring and adm inist rat ing t he hum an resource pool. This is t he cent ral pool of all hum an resources allocat ed t o t he I T organizat ion and all it s fract al suborganizat ions. This responsibilit y m ay be delegat ed in part t o ot her organizat ions. o Adm inist rat ing t he client relat ionship wit h bot h sponsoring client s and ot her non- I T organizat ions of t he business. o Producing and adm inist rat ing proj ect proposals. o Perform ing cent ralized facilit ies m anagem ent , procuring resources, and handling bookkeeping. This responsibilit y m ay be delegat ed in part t o ot her organizat ions. Adm inist rat ing t he relat ionship wit h ext ernal part ners. This includes cent ralized legal and cont ract m anagem ent .

Ow ne d r e sour ce s: o

Ch a n ge se t s ( a r t ifa ct s) : The I T- organizat ion m odel and im plem ent at ion plan, proj ect proposals, and cont ract ual and adm inist rat ive art ifact s.

Ow n e d a ct ivit ie s: Boot st rap t he I T organizat ion, proj ect init iat ion and t racking, t op- level ow ner of all operat ional workflows ( not of workflow definit ions, which are owned by t he chief archit ect as part of t he archit ect ural st yle) .

Th e Ar ch it e ct u r e Or ga n iz a t ion The archit ect ure organizat ion ( Arch- O) , shown in Figure 5.3, ensures a high ret urn on I T invest m ent s by providing professional syst em engineering skills t o t he ent ire I T organizat ion. I t prevent s t he ad hoc growt h of incom pat ible infrast ruct ures and com pet ing design philosophies. I t unit es t he m ost experienced I T personnel wit h a professional chief archit ect t o ensure t hat t he Convergent Archit ect ure is com m unicat ed, est ablished, and enforced properly.

-129-

Convergent Architecture

Chapter 5: The IT-Organization Model

Figur e 5 .3 : The archit ect ure organizat ion. W or k e r Role s a nd Re sponsibilit ie s Worker roles and responsibilit ies in t he archit ect ure organizat ion include t he following: ƒ

ƒ

ƒ

-130-

Chie f ( con ve r ge nt ) a r chit e ct . The chief archit ect is t he organizat ion m anager of t he archit ect ure organizat ion and t he single t op- level aut horit y on decisions regarding t he Convergent Archit ect ure and it s use. I n addit ion t o a high level of t echnical and com m unicat ion skills, t he chief archit ect m ust have a wide range of hands- on experience wit h various roles in real- world developm ent proj ect s. The logical career pat h leading t o t he required skill set st art s wit h work as a com ponent developer, t hen lead developer, and t hen convergent archit ect . These w orker roles are defined below. The chief archit ect has t he following specific responsibilit ies, which m ay be delegat ed t o anot her convergent archit ect ( discussed lat er) in t he organizat ion: Defines a specific inst ance of t he Convergent Archit ect ure for t he I T organizat ion and consist ent ly evolves t he inst ance. This includes t he coordinat ion and priorit izat ion of requirem ent s on t he archit ect ural st yle t oget her wit h t he requirem ent s m anager ( discussed lat er) . I t also includes working closely wit h t he archit ect ural I nt egrat ed Developm ent Environm ent ( I DE) specialist ( discussed lat er) . Monit ors and cont rols proper use of t he st yle across all syst em developm ent proj ect s. This includes review ing all syst em proj ect plans and m onit oring developm ent - process workflows. Operat ional problem s in workflows are delegat ed t o t he I T- organizat ion m anager, whereas

Convergent Architecture

ƒ

ƒ

ƒ ƒ

ƒ

m odificat ions in w orkflow definit ions are worked int o t he inst ance of t he Convergent Archit ect ure. Assist s in det ailed planning and buildup of t he I T support , syst em developm ent , and operat ional syst em s organizat ions. The chief archit ect regularly review s t hese organizat ions and works wit h t hem t o sim plify and opt im ize overall operat ions from t he perspect ive of t he t hree pillars of holist ic archit ect ure: proj ect design, business design, and syst em design. Select s t echnologies and designat es t he resource owner for t he t echnology. The chief archit ect ident ifies t he need for sent inels for specific t echnologies and works t oget her wit h t he respect ive resource owner t o define t he sent inel. Reviews proj ect t eam s t o ensure adequat e skill set s and preparat ion. Assist s lead developers as a part icipant in syst em developm ent proj ect s ( discussed lat er) , part icularly in t he proj ect incept ion and elaborat ion phases. I s a Convergent Archit ect ure- specific consolidat ion of t he following RUP w orker roles: archit ect , process engineer, business process analyst , archit ect ure reviewer, design reviewer, business m odel reviewer, and proj ect reviewer from t he I T- archit ect ure perspect ive.

AM FL Y

ƒ

Chapter 5: The IT-Organization Model

TE

Ow n e d r e sour ce s: o Cha nge se t s ( a r t ifa ct s) : o Conve r ge n t Ar chit e ct ur e st yle r e fe r e nce . This describes an organizat ion- specific inst ance of t he Convergent Archit ect ure as defined in t his book. The inst ance m ay be a one- t o- one applicat ion of t he ent ire st yle as described in t his book or a docum ent ed variant t hat rem ains com pat ible wit h t he archit ect ural and developm ent m odels as described in t his book. o Asse m bly a r chit e ct ur e r e vie w . This is a review report confirm ing and explaining t he archit ect ural com pliance of a part icular assem bly com ponent . o Unifie d glossa r y. This consolidat es all glossaries produced by assem bly developers ( discussed lat er) . o Se nt ine ls. All sent inels describing t he archit ect ureconform posit ioning and t he use of t echnology wit hin t he I T organizat ion, including it s syst em developm ent proj ect s. o Top- level OPR business m odel and cont ext diagram s. o Specialized Technologies: None pre- defined. Ow n e d a ct ivit ie s: T- bar business analysis and archit ect ural evolut ion. ƒ

Conve r ge n t a r chit e ct . [ 2] This apprent ice or assist ant t o t he chief archit ect gains experience as a convergent archit ect while assist ing t he chief archit ect in day- t o- day act ivit ies. The num ber of convergent archit ect s required depends on t he size and m at urit y of t he I T organizat ion. A convergent archit ect accom panies each syst em developm ent proj ect and serves as t he t echnology- versed count er- part t o t he syst em proj ect m anager ( discussed lat er) . His or her prim ary role is t o guarant ee cross- proj ect int egrit y of t he archit ect ure, t im ely

-131-

Team-Fly®

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 5: The IT-Organization Model

feedback bet ween t he archit ect ure organizat ion and ot her I T organizat ions, and m ent oring of lead developers. The num ber of convergent archit ect s also m ust suffice t o ensure adequat e redundancy and long- t erm cont inuit y in t his crit ical area. This worker is a Convergent Archit ect ure- specific inst ance of t he following RUP worker role, t he sam e as t he chief archit ect previously. Spe a k e r of t he a r chit e ct ur e . This com m unicat or professionally explains and t eaches t he archit ect ure t o it s m any st akeholders at all levels of t he organizat ion. Due t o t he crit ical im port ance of t he I T archit ect ure in all aspect s of t he ent ire business, it is im port ant t hat it be properly com m unicat ed at all levels of t he business. The speaker of t he archit ect ure focuses on t his specialized t ask. This person m ust be a m ast er in t he skills required t o com m unicat e t he feat ures, goals, st at us, advant ages, and plans of t he archit ect ure and t he archit ect ure organizat ion. The chief archit ect does not necessarily fulfill t his role. I n fact , in large organizat ions, t his speaker frees up t he chief archit ect t o carry out his or her core responsibilit ies. Re quir e m e nt s m a na ge r . This cent ral figure organizes, refines, and priorit izes t he cont inuous st ream of business and t echnical requirem ent s from all sources. The requirem ent s m anager is t he single, official sink for all requirem ent request s t hat do not have a predefined sink in anot her I T organizat ion or soft ware developm ent proj ect . Any requirem ent wit hout a clearly defined and recept ive sink lands w it h t he requirem ent s m anager. Once requirem ent s have been sift ed, sort ed, and priorit ized, t he requirem ent s m anager t hen dispat ches t he requirem ent s t o organizat ion m anagers ( according t o t heir organizat ion's responsibilit ies) for t he planning of new proj ect s or organizat ional changes. This worker is t he Convergent Archit ect urespecific consolidat ion of t he follow ing RUP worker roles: requirem ent s reviewer and change cont rol m anager. [ 3] Ow n e d r e sour ce s: o

Cha nge se t s ( a r t ifa ct s) : Requirem ent s pool.

o

Spe cia lize d t e ch nologie s: Rat ional Requisit e- Pro. Ow ne d a ct ivit ie s: Global requirem ent s m anagem ent

o

Ar chit e ct ur a l I D E spe cia list . This t ool specialist is t he single t op- level aut horit y on t he use and evolut ion of t he I T- archit ect ural I DE and ot her developm ent support t ools used in t he I T organizat ion. He or she defines, refines, and m aint ains t he reference t ool t opology. The prim ary responsibilit y is t o ensure t hat t he t ools opt im ally support t he goals and feat ures of t he archit ect ural st yle and t hat t he t ools rem ain consist ent and com pat ible across proj ect s. This w orker norm ally has ext ensive experience as a developm ent t oolsm it h ( discussed lat er) . This worker is a Convergent Archit ect ure- specific inst ance of t he following RUP worker role: t ool specialist .

Ow ne d r e sour ce s: o Cha nge se t s ( a r t ifa ct s) :

-132-

Convergent Architecture

ƒ ƒ

Chapter 5: The IT-Organization Model

I T- a r chit e ct ur a l I D E. Technology proj ect ion com ponent ( m odeling st yle guides, cart ridges) , inst allat ion kit for I T- archit ect ural I DE m odules, and inst allat ion verificat ion t est s. Tools int e gr a t e d by t he a r chit e ct ur a l I D E. JBuilder Java I DE, Rat ional Rose Modeler, J2EE Applicat ion Server ( for exam ple, Borland BAS, BEA WLS, I BM WebSphere, and so on) , Apache WebServer, persist ent resource m anager for J2EE applicat ion server ( for exam ple, TopLink, Oracle, Sybase) , Cygnus GNU Tools. o Spe cia lize d t e chn ologie s: Sam e as change set .

[ 2]

A syst em archit ect , as defined by t he RUP, who is effect ively fulfilling t his role in t he cont ext of Convergent Archit ect ure is a convergent archit ect . [ 3]

This is a st yle- specific applicat ion of t he concept s form ulat ed in RUP Technical Whit e Paper TP505, " Applying Requirem ent s Managem ent wit h Use- Cases" ( Oberg 2000) .

The I T Su ppor t Or ga n iz a t ion The I T support organizat ion ( I T- Sup- O) provides t he t echnical infrast ruct ure and services for all I T organizat ions except for t he operat ional syst em s organizat ion. I n ot her words, it provides support for t he com plet e developm ent - orient ed infrast ruct ure. Oft en, developm ent support environm ent s are neglect ed in proj ect plans or are delegat ed t o t he persons responsible for t he operat ional syst em s of an organizat ion, and bot h approaches result in m aj or problem s. Just as t he environm ent in an aut om obile fact ory does not m uch resem ble t hat of a service st at ion, t he environm ent required for effect ive I T syst em developm ent is m uch different from t he environm ent in which t he I T syst em s event ually operat e. I n addit ion, t he syst em developers cannot be responsible for bot h developm ent of new I T syst em s and developm ent and m aint enance of t heir support ing environm ent at t he sam e t im e. These are t w o com plet ely different j obs. Experience has show n t hat it is m uch m ore effect ive t o have a well- defined I T support organizat ion t o handle t he m yriad support act ivit ies required by syst em developm ent proj ect s. Since t he syst em developm ent proj ect s adhere t o t he sam e I T- archit ect ural st yle, t he I T support organizat ion can bet t er reuse it s syst em s and services across developm ent proj ect s. As always, such reuse enables superior opt im izat ion of support procedures and syst em s—everybody wins.

As indicat ed in Figure 5.4, t he I T support organizat ion is part it ioned int o four suborganizat ions. All it s responsibilit ies and roles, aside from t hose com m on t o every I T organizat ion, are delegat ed t o t he suborganizat ions, which are covered individually in t he following sect ions.

-133-

Convergent Architecture

Chapter 5: The IT-Organization Model

Figur e 5 .4 : The I T support organizat ion. The I nfr a st r uct ur e a nd Ba se Syst e m s Or ga niza t ion New, innovat ive syst em s can only be developed effect ively once t he fundam ent al base syst em s on which t he developm ent effort depends are robust and well organized. The infrast ruct ure and base syst em s organizat ion ( I nfraBas- O) is responsible for providing t hese fundam ent al base syst em s. The chief archit ect defines t he com m on- denom inat or syst em environm ent s t oget her wit h t his organizat ion. The infrast ruct ure and base syst em s organizat ion t hen im plem ent s and support s t he environm ent for all I T organizat ions except for t he operat ional syst em s organizat ion. Cont inuit y and consist ence wit h t he operat ional syst em s organizat ion are m aint ained t hrough frequent , it erat ive proj ect int eract ion in t he due course of syst em developm ent proj ect s and t he act ivit ies of t he t est cent er organizat ion ( see t he follow ing sect ion) .

W or k e r Role s a n d Re spon sibilit ie s Worker roles and responsibilit ies in t he infrast ruct ure and base syst em s organizat ion include t he following: ƒ

I nfrast ruct ure and base syst em s organizat ion m anager. I n addit ion t o t he responsibilit ies of an organizat ion m anager, t he m anager of t he infrast ruct ure and base syst em s organizat ion is specifically responsible for t he following: o Defining t he basic sy st em environm ent and services wit h t he chief archit ect and ensuring t he robust im plem ent at ion of t his environm ent . o Procuring, inst alling, adm inist rat ing, support ing, and m aint aining t he infrast ruct ure ( bot h hardware and soft ware) in at least t he following areas: net w orks, file servers, and applicat ion servers for general use; operat ing syst em s; office applicat ions; securit y and backup syst em s; and basic ut ilit ies as defined by t he chief archit ect . o Defining and m aint aining t he t ools and associat ed procedures used t o support t he base infrast ruct ure. Ow ne d r e sour ce s: o Cha nge se t s ( a r t ifa ct s) : I nfrast ruct ure and base syst em s guide. This guide docum ent s t he st ruct ure, inst allat ion, m aint enance, and use of t he infrast ruct ure and base syst em s for t he respect ive user of t he base syst em .

-134-

Convergent Architecture

ƒ

Chapter 5: The IT-Organization Model

Syst e m a dm inist r a t or . This specialist in syst em adm inist rat ion operat es and m aint ains t he infrast ruct ure. This worker is a Convergent Archit ect ure- specific inst ance of t he follow ing RUP worker role: syst em adm inist rat or.

The Ch a n ge a nd Configur a t ion M a na ge m e nt Or ga niza t ion The change and configurat ion m anagem ent organizat ion ( CCM- O) houses t he t eam and t he syst em s required t o effect ively m anage t he versioned and archived art ifact s of t he I T organizat ion. Versioned art ifact s are t hings such as source code t hat are m anaged online in t erm s of t heir precise versions. These versions m ust be reproducible at any t im e. A change and configurat ion m anagem ent syst em support s t his com plex t ask. Archived art ifact s are one of t wo t hings: They are eit her art ifact s t hat do not require t he precise t racking of version hist ory, or t hey are art ifact s t hat cannot be m anaged reasonably wit hin a configurat ion m anagem ent syst em . The lat t er m ay st ill be versioned as part of a syst em configurat ion. I n bot h cases, m echanism s m ust exist t o ident ify and m anage t hese art ifact s out side t he configurat ion m anagem ent syst em and in m any cases offline. Exam ples of offline archived art ifact s are CDs cont aining soft ware kit s or specialized, soft ware- version- dependent hardware such as a sm art - card reader.

W or k e r Role s a n d Re spon sibilit ie s Worker roles and responsibilit ies in t he change and configurat ion m anagem ent organizat ion include t he following: ƒ

ƒ

-135-

Ch a nge a n d configur a t ion m a n a ge m e nt or ga niza t ion m a na ge r . I n addit ion t o t he responsibilit ies of an organizat ion m anager, t he m anager of t he change and configurat ion m anagem ent organizat ion is specifically responsible for t he follow ing: o Defining t he syst em and service levels for bot h archived and versioned pools of art ifact s based on t he proj ect ions of t he ot her I T organizat ions. This is done in conj unct ion w it h t he m anagers of each I T organizat ion and t he chief archit ect . The granularit y, part it ioning, and quant it ies of versioned and archived art ifact s can be reasonably est im at ed due t o t he com m on com ponent and process m odels and t he com m on archit ect ural I DE em ployed across all proj ect s in t he archit ect ural st yle. o Managing t he soft w are invent ory, library, and licenses, as well as t he hardware invent ory. o Cat aloging exist ing convergent com ponent s for reuse and assist ing ot hers in locat ing t hem . This includes m aint enance of consist ent nam ing convent ions and a clean, unam biguous nam e space at t he level of convergent com ponent s. o Maint aining offline soft ware archive and lit erat ure library. Configur a t ion m a na ge r . This specialist in configurat ion m anagem ent operat es and m aint ains t he versioned and archived pools. The configurat ion m anager has t he following specific responsibilit ies: o St ruct uring and opt im izing t he versioning and archiving act ivit ies according t o schem es defined by t he rat ional

Convergent Architecture

o

o

o

o

Chapter 5: The IT-Organization Model

unified change m anagem ent ( UCM) m et hodology for t he art ifact s and change set s in t he Convergent Archit ect ure. The developm ent m odel and t he archit ect ural I DE specify m any art ifact s and change set s, such as t he convergent com ponent s, as well as t heir part it ioning. Support ing t he users in t he ent ire I T organizat ion in effect ively m eet ing t heir specific change and configurat ion m anagem ent requirem ent s. I n part icular, t his ent ails creat ing a configurat ion m anagem ent reference according t o t he UCM for each assem bly com ponent . Creat ing a base or t em plat e configurat ion m anagem ent reference and using it as a basis for assem bly- specific configurat ion m anagem ent references. Assuring t hat all art ifact s required t o reproduce assem blies are versioned or archived. This is carried out in conj unct ion wit h t he t est cent er organizat ion ( discussed lat er) . Exam ples of t hese art ifact s include m odels, generat ed sources, build environm ent s, t ools, and ut ilit ies, t hat is, essent ially everyt hing required t o reproduce t he developm ent environm ent . Convergent Archit ect ure- specific inst ance of t he following RUP worker role: configurat ion m anager

Ow ne d r e sour ce s: ƒ

Cha nge se t s ( a r t ifa ct s) : Versioned UCM pool, archived pool, UCM usage guidelines, base UCM configurat ion m anagem ent reference.

ƒ

o

Spe cia lize d t e ch nologie s: ClearCase UCM syst em including client s. ƒ Re posit or y t oolsm it h. This CCM syst em expert defines, deploys, m aint ains, and evolves t he UCM infrast ruct ure and t ool environm ent . The specific definit ion of t he CCM syst em and accom panying t ools is carried out t oget her w it h t he chief archit ect . The reposit ory t oolsm it h is also responsible for t ailoring t he CCM- relat ed t ools for effect ive use w it h t he archit ect ural I DE and for support ing users in t his cont ext . He or she works closely w it h t he developm ent t oolsm it h and configurat ion m anager. Ow ne d r e sour ce s: ƒ

ƒ

Cha nge se t s ( a r t ifa ct s) : None. Spe cia lize d t e ch nologie s: ClearCase UCM syst em including client s.

The Pr oj e ct I nfor m a t ion, Eve nt s, a nd Tr a ining Or ga niza t ion The proj ect inform at ion, event s, and t raining organizat ion ( PET- O) helps t he I T organizat ion achieve opt im al use and reuse of inform at ion across organizat ional and proj ect boundaries. I t is responsible for t he proact ive definit ion of effect ive com m unicat ion and learning m echanism s for t he ent ire organizat ion. I t provides a

-136-

Convergent Architecture

Chapter 5: The IT-Organization Model

pragm at ic plat form for t he t im ely flow and availabilit y of valuable inform at ion, which is oft en lost in syst em developm ent organizat ions. I t achieves t his, for exam ple, t hrough t he proact ive design of how inform at ion will be harvest ed and st ruct ured bot h in t he I T organizat ion and for t he end- user of it s syst em developm ent product s. I t t hen provides well- defined access channels t o t his inform at ion such as a Web sit e, regular event s, and educat ional m at erial. I n addit ion t o planning and st ruct uring t he inform at ion, an im port ant goal of t his organizat ion is t o support t he direct , well- coordinat ed cont ribut ion t o t he inform at ion pool by all st akeholders. Last ly, t his is t he organizat ional hom e of all workers specializing in t he consolidat ion, present at ion, and publishing of inform at ion in t he I T organizat ion.

W or k e r Role s a n d Re spon sibilit ie s Worker roles and responsibilit ies in t he proj ect inform at ion, event s, and t raining organizat ion include t he following: ƒ

ƒ

ƒ ƒ ƒ

Pr oj e ct infor m a t ion, e ve nt s, a nd t r a ining or ga niza t ion m a na ge r . I n addit ion t o t he responsibilit ies of an organizat ion m anager, t he m anager of t he proj ect inform at ion, event s, and t raining organizat ion is specifically responsible for t he follow ing: o Working wit h ot her organizat ions and proj ect s t o define t heir part icular inform at ion, docum ent at ion, and t raining requirem ent s. o Coordinat ing and adm inist rat ing educat ional and inform at ion event s appropriat e t o t he size and plans of t he ot her organizat ions. o Providing t he cent ral definit ion, coordinat ion, and support for t he suit e of elect ronic office t ools used by t he ent ire I T organizat ion. Te ch nica l w r it e r . This specialist in t echnical docum ent at ion produces t he final form s of any official docum ent s. He or she is also responsible for t he select ion, preparat ion, and m aint enance of publishing t ools and t he product ion of docum ent st yles and t em plat es. These preparat ory art ifact s are defined t oget her wit h t he chief archit ect . The t echnical w rit er part icipat es in syst em developm ent proj ect s t o ensure t hat highqualit y docum ent at ion is produced in t he course of t he norm al developm ent act ivit ies leveraging m axim um synergies bet ween cont ribut ors. This worker is a Convergent Archit ect ure- specific inst ance of t he following RUP worker role: t echnical w rit er. o Ow ne d r e sour ce s:

Cha nge se t s ( a r t ifa ct s) : Docum ent at ion developm ent set ( docum ent at ion st yle guide, docum ent st yle t em plat es) , design docum ent at ion, end- user docum ent at ion. Spe cia lize d t e ch nologie s: Fram eMaker, Quadralay Webw orks. Cour se de ve lope r . This specialist focuses on t he developm ent of educat ional m at erial and is ot herwise analogous t o t he t echnical writ er. He or she is oft en an experienced educat or ( discussed lat er) . This w orker const it ut es

-137-

Convergent Architecture

o ƒ

ƒ ƒ ƒ

o ƒ ƒ ƒ

ƒ ƒ

ƒ

Chapter 5: The IT-Organization Model

a Convergent Archit ect ure- specific inst ance of t he following RUP worker role: course developer. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : Training developm ent set ( t raining st yle guide, t raining st yle t em plat es) , developer courses, and end- user courses Spe cia lize d t e ch nologie s: PowerPoint . Educa t or . This expert delivers t raining courses in his or her part icular field using m at erials prepared by t he course developer. This w orker is oft en also t he course developer. W e bD ir e ct or . This specialist in Web sit e definit ion set s up, adm inist ers, and support s t he use of a cent ral Web sit e for t he I T organizat ion, t he I T- OrgWebsit e. This Web sit e direct ly reflect s t he st ruct ure of t he I T organizat ion. The WebDirect or works wit h all ot her organizat ion m anagers t o define and finet une t heir Web cont ent , provision, and m aint enance. He or she is also responsible for t he select ion of t ools and m aint enance of t he ent ire Web infrast ruct ure. I T organizat ions are inst ruct ed by t he WebDirect or on how t o ent er and m anage t heir own pages and cont ent in t he Web sit e. He or she cont inually support s, m onit ors, and opt im izes t he process of dist ribut ed inform at ion cont ribut ion. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : The I T- Org- Web sit e, which is where all proj ect docum ent s, report s, and general inform at ion are published in st andard HTML form at . Spe cia lize d t e ch nologie s: HTML is used for all I T organizat ion int ernal docum ent s and int ernal com m unicat ions. Microsoft Front Page ( or an equivalent t ool) is used for edit ing, j ust - in- t im e t eam cont ribut ion, and cont ent m anagem ent . Transm ission of docum ent s is eit her via e- m ail of via t he I T- Org- Web sit e depending on t he t arget audience and inform at ion half- life. Visio ( or equivalent ) wit h HTML out put is used for cont ext - free graphics such as cont ext diagram s. Gr a phic a r t ist . This specialist in graphic design and relat ed t ools is responsible for t he end product ion of all graphic design- int ensive art ifact s. Exam ples of such art ifact s include user- int erface icons and graphics for packaging, logos, Web logos, inst allat ion logos, st ereot ype logos, docum ent at ion figures, and educat ional and present at ion graphics. The graphic art ist also defines t he specialized graphic t ool and form at landscape wit h t he chief archit ect and t he ot her specialist s in t he PET organizat ion. He or she m aint ains t he t ools and provides user support for ot hers using t he t ools and form at s produced by t he t ools. This worker const it ut es a Convergent Archit ect ure- specific inst ance of t he following RUP worker role: graphic art ist . Com put e r e r gon om ics a nd GUI e x pe r t ( CEG) . This specialist in t he layout , flow, and general usabilit y of GUI s assist s accessor developers ( discussed lat er) . The CEG ( pronounced " keg" ) is in part icular involved in t he product ion of ergonom ic, aest het ically pleasing represent ers. Thus, he or she m ust be an expert in t he high- end Web page design t ool select ed for represent er cust om izat ion. This w orker also develops t he look- and- feel guidelines for t he specific organizat ion or indust ry segm ent and m ay develop reusable accessor com ponent s and accessor- generat ion t em plat es at t he

-138-

Convergent Architecture

o ƒ

ƒ

Chapter 5: The IT-Organization Model

request of t he archit ect ure organizat ion out side t he cont ext of a syst em developm ent proj ect . Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : GUI look- and- feel guidelines, represent er GUI of UI - accessor com ponent s. Spe cia lize d t e ch nologie s: Macrom edia Ult raDev ( or equivalent ) . The Te st Ce nt e r Or ga niz a t ion The t est cent er organizat ion ( Test Cent er- O) ensures t hat nonpart isan, effect ive t est ing skills and coordinat ion cont ribut e t o t im ely qualit y cont rol in t he I T organizat ion. Professional t est ing is a com plex area. I t is an ext rem ely nonst andardized field involving com plex t echnologies as well as difficult t radeoffs regarding effort and payoff. A well- run t est organizat ion can save an organizat ion significant t im e and m oney, whereas a poorly run t est organizat ion can cause m ore problem s t han it solves. Thus, a professional t est ing organizat ion is required t o ensure t hat t he proper decisions are m ade, t hat proper preparat ion t akes place, t hat well- m anaged t est ing is perform ed, and t hat t he result s cont ribut e t o im proving overall qualit y and efficiency. I n addit ion, since t est design, preparat ion, and execut ion affect every I T organizat ion at som e point in t he developm ent life cycle, t his organizat ion is required t o provide t he necessary expert ise, focus, and cont inuit y in t his im port ant area.

W or k e r Role s a n d Re spon sibilit ie s ƒ

o

o

o

o

Worker roles and responsibilit ies in t he t est cent er organizat ion include t he following: Te st m a n a ge r ( t e st ce nt e r m a na ge r ) . The t est m anager is t he organizat ion m anager of t he t est cent er organizat ion and t he single t op- level aut horit y on decisions regarding t he Convergent Archit ect ure and it s use. I n addit ion t o t he responsibilit ies of an organizat ion m anager, t he t est m anager is specifically responsible for t he following: Defining and m aint aining t he t est infrast ruct ure corresponding in charact er wit h t he current or planned infrast ruct ure in t he operat ional syst em s organizat ion, including all real const raint s of t he operat ional environm ent . Working wit h t he chief archit ect t o cust om ize t he t est feat ures of t he developm ent m odel ( for exam ple, unit t est ing feat ures of convergent com ponent s) and t he archit ect ural I DE t o m eet specific requirem ent s of t he organizat ion. This result s in t he specific t est ing guidelines docum ent and, in som e cases, t he addit ion of specialized t est ing t ools and infrast ruct ure t o t he archit ect ural I DE. Working wit h t he lead developer and deploym ent m anager in each syst em developm ent proj ect t o specify t he assem bly t est plan, including t he t est environm ent . Then t he t est m anager allocat es and coordinat es one or m ore t est ers t o assist w it h unit t est ing and t o carry out assem bly t est ing. Reviewing t est er result s and t est report s and det erm ining in t he lat er it erat ions of a proj ect w het her an assem bly has reached t he init ial operat ion capabilit y and, as such, m ay be released for deploym ent by t he t ransit ion organizat ion ( discussed lat er) .

-139-

Convergent Architecture

o

ƒ

o

ƒ

ƒ ƒ

o

ƒ

ƒ

Chapter 5: The IT-Organization Model

Developing long- t erm evaluat ions and st at ist ics regarding not only t he qualit y and end result s of t est s in general, but also t he qualit y of t est abilit y in t he I T organizat ion, and providing t his as regular and t im ely feedback in t he form of a consolidat ed qualit y evaluat ion report t o t he ot her I T organizat ions or t hrough t he requirem ent s m anager. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : Test ing guidelines docum ent , including guidelines for t he organizat ion's specific t est infrast ruct ure, assem bly t est plan, and consolidat ed qualit y evaluat ion report . Te st e r : This t est specialist set s up and adm inist ers t he t est environm ent ( applicat ion server, assem bly com ponent s) and carries out t he t est according t o t he assem bly t est plan as a part icipant in a syst em developm ent proj ect . This is a Convergent Archit ect ure- specific inst ance of t he RUP worker role: t est er. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : Assem bly t est result s report . Spe cia lize d t e ch nologie s: None pre- defined. Te st ing t oolsm it h. This specialist in t he t est t ools and infrast ruct ure support s t he int egrat ion and operat ion of t est t ools in t he archit ect ural I DE. This expert user of t he t est ing com ponent s and capabilit ies of t he I DE support s users of t hese feat ures t hroughout t he developm ent life cycle. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : Specialized t est ing t ools if required. Spe cia lize d t e ch nologie s: JUnit .

Th e Syst e m D e ve lopm e n t Or ga n iza t ion The syst em developm ent organizat ion ( SysDev- O) is where t he act ual developm ent and delivery of all convergent com ponent s t ake place. I n t his organizat ion, effect ive syst em developm ent proj ect s are set up in t erm s of t wo predefined t eam s, as show n in Figure 5.5. These t eam s are specially configured t o best address t wo different t ypes of developm ent proj ect s. Assem bly developm ent t eam s are specialist s in t he highly int egrat ive aspect s required t o deliver ent ire assem bly com ponent s. Com ponent developm ent t eam s specialize in t he reusable part s of assem blies and usually work in t he cont ext of an assem bly developm ent t eam . The t eam s define t he set s of w orkers and responsibilit ies t hat best com plem ent each ot her during t he syst em developm ent life cycle. [ 4] The developm ent process described in Chapt er 6 w ill cover t he coordinat ion and flow of act ivit ies in and around t hese predefined t eam s.

-140-

Convergent Architecture

Chapter 5: The IT-Organization Model

Figur e 5 .5 : The syst em developm ent organizat ion. W or k e r Role s a nd Re sponsibilit ie s

o o o

ƒ

ƒ

o

AM FL Y

o

TE

ƒ

Worker roles and responsibilit ies in t he syst em developm ent organizat ion include t he following: Syst e m de ve lopm e nt or ga niz a t ion m a na ge r . I n addit ion t o t he responsibilit ies of an organizat ion m anager, t he m anager of t he syst em developm ent organizat ion is specifically responsible for t he following: Support ing t he effect ive product ion of convergent com ponent s by providing an opt im ized organizat ion environm ent for t he ent ire pool of syst em developm ent proj ect s. This worker is involved in t he init iat ion of each proj ect and accom panies all proj ect s from t he perspect ive of organizat ional support and synergies. The significance of t his responsibilit y increases wit h t he num ber of proj ect s in t he proj ect pool. Assuring opt im al allocat ion of developers and resources t o and across syst em developm ent proj ect s. Pro- act ive t raining of developers and est ablishing an opt im al t eam developm ent environm ent . Providing consolidat ed feedback based on t he observat ions of m anifold parallel syst em developm ent proj ect s, form ulat ing feedback in t he form of requirem ent s t o t he requirem ent s m anagers, and w orking w it h t he chief archit ect t o refine and opt im ize t he definit ion of t he syst em developm ent proj ect and t he canonical developm ent t eam s ( discussed lat er) for t he specific organizat ion. D e ve lopm e nt t oolsm it h. This t rained and experienced user of t he archit ect ural I DE m akes a proj ect - specific configurat ion of t he I DE and archit ect ure- com pliant ext ensions/ m odificat ions t o t he I DE in t he cont ext of specific proj ect s. He or she helps developers effect ively apply t he I DE by set t ing up and t uning t he developm ent environm ent t oget her wit h each developer. He or she cont inually evaluat es t he I DE from t he proj ect perspect ive and subm it s new requirem ent s or change request s t o t he archit ect ural I DE specialist or requirem ent s m anager. Syst e m pr oj e ct m a n a ge r . I n addit ion t o being a proj ect m anager, t his is a specialist in syst em developm ent proj ect s, as defined in t he following sect ion, and is specifically responsible for t he following: Boot st rapping and accom panying a syst em developm ent proj ect as defined in t he following sect ion according t o t he developm ent process m odel as present ed in Chapt er 6. This includes init ial proj ect analysis and planning and m anaging proj ect it erat ions according t o t he proj ect m anagem ent workflow ( see Chapt er 6) .

-141-

Team-Fly®

Convergent Architecture

o o ƒ

ƒ ƒ

Chapter 5: The IT-Organization Model

Building and support ing assem bly developm ent t eam s and t heir com ponent developm ent t eam s ( discussed lat er) . Convergent Archit ect ure- specific inst ance of t he following RUP worker role: proj ect m anager. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : Syst em proj ect plan ( long- t erm developm ent st rat egy, current it erat ion plan wit h work orders for bot h assem bly and com ponent developm ent proj ect s) , but no predefined specialized t echnologies. Spe cia lize d t e ch nologie s: None pre- defined. D e ve lope r . A collect ive t erm denot ing any developer in t he syst em developm ent organizat ion. This includes t he lead developers, assem bly developers, com ponent developers, and accessor developers, covered in t his chapt er. The Syst e m D e ve lopm e nt Pr oj e ct A syst em developm ent proj ect is som et hing specific in t he Convergent Archit ect ure. Just as in m ost organizat ions, t he I T organizat ion set s up explicit proj ect s t o creat e valuable processes and resources. The processes and resources produced by a proj ect are t hen used by organizat ions in ongoing processes or as building blocks in ot her proj ect s. Thus, proj ect s are t he cent ral driver in an infinit e cycle of progress and change. Alt hough proj ect s in all organizat ions share com m on feat ures, m y focus here is on t he developm ent of I T syst em s—on syst em developm ent proj ect s. I speak of syst em developm ent inst ead of soft ware developm ent because t he result ing syst em s are not lim it ed t o pure soft ware. Alt hough m y focus here is on I T, t hese proj ect s also include aspect s of business organizat ion t hat have lit t le t o do wit h t echnology. A syst em developm ent proj ect also addresses t he infrast ruct ure and operat ional elem ent s of syst em s t hat have m ore t o do wit h t he configurat ion and m aint enance of hardware, packaged- soft ware, and hum an infrast ruct ure t han t hey do wit h soft ware developm ent . The consolidat ion of t hese various aspect s helps us produce m ore effect ive syst em s, not j ust a piece of soft ware. Syst em developm ent proj ect s in t he I T cont ext are t he raison d'êt re of t he syst em developm ent organizat ion, regardless of whet her t he syst em is act ually developed in- house, is out sourced, or, as is m ost oft en t he case, is a m ixt ure of bot h. Alt hough st ill called developm ent proj ect s, t hese proj ect s also address t he longt erm aspect s of t he syst em life cycle. To achieve t his, t he st ruct ure and focus of t hese proj ect s m ust deal explicit ly w it h t he dichot om y of short - t erm deliverables versus long- t erm ret urns. The short - and long- t erm perspect ives of syst em developm ent form t w o com pet ing poles in any developm ent organizat ion. Whereas t he client s of developm ent proj ect s norm ally are int erest ed only in t heir short - t erm , im m ediat ely t angible deliverables, I T archit ect s are also concerned wit h t he long- t erm , oft en hidden qualit ies of syst em s. Most client s have an acut e problem . They only want t o pay for t he m inim um effort required t o solve t heir part icular problem . On t he ot her hand, t he I T archit ect realizes t hat a purely short - t erm focus t o syst em developm ent will cause significant long- t erm problem s. I ronically, t he cost s t o rect ify t hese problem s event ually are borne by t he client , so professional I T archit ect ure also is in t he client 's int erest . The I T archit ect det erm ines how longt erm planning and invest m ent can significant ly reduce t he cost s of each client over t im e. On t he ot her hand, a purely long- t erm focus t o syst em developm ent oft en

-142-

Convergent Architecture

Chapter 5: The IT-Organization Model

ends up in an unchecked academ ic exercise, w hich, sooner or lat er, will be condem ned by client s as " ut opist " —usually wit h good reason. Alt hough a m odern it erat ive developm ent approach helps a proj ect deal wit h t hese poles wit hin a single proj ect , it is not very specific about how t hey should be dealt wit h across m ult iple proj ect s and across m ult iple generat ions of syst em s. The syst em developm ent organizat ion em phasizes t he following specific short - and long- t erm aspect s of developm ent t o help proj ect s and proj ect t eam s im prove t he equilibrium bet ween t hese t w o poles.

Lon g- Te r m : D e live r Bu sin e ss- Ce n t r ic OPRs When a convergent com ponent is ident ified as significant during t he businessm odeling workflow, part icular at t ent ion is paid not t o refine it int o an accessorspecific com ponent t hat m eet s only t he punct ual requirem ent s of a part icular applicat ion. I nst ead, care is t aken t o also represent t he inherent feat ures of t he business dom ain, regardless of t he part icular applicat ion. To achieve t his, dom ain expert s and t he lead developers do not focus only on t he accessor use cases associat ed wit h a part icular accessor com ponent . They know t hat t he OPR com ponent s of t he business m ay be used by any num ber of accessors, m any of t hese accessors being current ly undefined. Thus, t he business use case scenarios are em ployed t o help t he dom ain expert s and designers ident ify m ore businesscent ric, in cont rast wit h problem - cent ric, OPRs. These OPRs result in crossapplicat ion convergent com ponent s t hat can be reused and evolved over t im e m ore easily from t he long- t erm perspect ive, according t o t he requirem ent s of t he business at large. However, t o prevent t his from becom ing an academ ic exercise, t his evolut ion t akes place in t he cont ext of individual syst em developm ent proj ect s, each driven by t he needs of a part icular assem bly com ponent . This approach is com pat ible wit h t he short - t erm aspect discussed lat er. A good exam ple of t his long- t erm aspect is t he classic sit uat ion of a cust om er com ponent t hat will be used by m anifold assem blies in m any different business cont ext s. I n t he case where a cust om er is required by a part icular applicat ion, t hat is, by an accessor com ponent , t he design t eam first at t em pt s t o locat e an exist ing assem bly t hat owns a cust om er com ponent . I t t hen reuses t his com ponent from wit hin t he new assem bly. I n t he advent of new requirem ent s, t he t eam adds or adapt s t he responsibilit ies of t his com ponent in t he business obj ect m odel t o also fit t he requirem ent s of t he new assem bly. Manipulat ion or adapt at ion of t he cust om er com ponent is coordinat ed wit h it s resource owner. Depending on t he num ber of deployed assem blies already using t he cust om er com ponent , m ore planning and coordinat ion effort m ay be required t han j ust developing a new one for t he specific case. Thus, at first glance, t he process of reuse and evolut ion is m ore cost ly. However, t he invest m ent clearly pays off in t he long t erm by avoiding expensive and error- prone coordinat ion of m ult iple cust om er represent at ions across syst em s. I f t his invest m ent is not m ade at t his point in t he developm ent life cycle, risks and qualit y problem s due t o soft ware ent ropy increase, and t he cost s t o reverse t his t rend rise st eadily. To keep t he act ivit y of long- t erm opt im izat ion from digressing int o an academ ic exercise in business design and com ponent reuse, I int roduce t he second aspect of equally high priorit y.

-143-

Convergent Architecture

Chapter 5: The IT-Organization Model

Sh or t - Te r m : D e live r a Bu sin e ss- Re le va n t Asse m bly Com pon e n t Syst em developm ent proj ect s need m easurable short - t erm goals. This priorit y is addressed by set t ing up each proj ect around a deliverable assem bly com ponent . The assem bly com ponent s are applicat ion- driven. As described in t he convergent com ponent s m et am odel, t hey exist t o encapsulat e and inst all a well- defined business applicat ion wit h all com ponent s required by t he applicat ion. This applicat ion- specific focus also serves t o channel and drive t he proj ect t oward it s concret e deliverable. The concret e applicat ion is represent ed direct ly by t he accessor com ponent s of an assem bly. Accessor use cases form ulat e t he client 's im m ediat e requirem ent s on t he syst em . Reusable accessor com ponent s also m ay be leveraged or creat ed, of course. The requirem ent s of t he accessors drive and channel t he det ailed planning and im plem ent at ion of an assem bly com ponent , t he short - t erm deliverable of a syst em developm ent proj ect . The subt le balance bet ween t he t wo poles of long- and short - t erm focus has a significant im pact on t he ret urn on I T invest m ent s. Moving t oo close t o eit her of t he poles can cause t he I T organizat ion t o m iss it s pot ent ial by several orders of m agnit ude. I t is difficult t o avoid t he t em pt at ion of short - t erm focus in t oday's world, where t he horizon oft en ends at t he next quart erly report . One of t he best ways t o keep an organizat ion on t he right t rack is t o have t he proper const ellat ion of experience and skills in syst em developm ent t eam s. This is t he focus of t he next subsect ions. The Ca non ica l D e ve lopm e nt Te a m The canonical developm ent t eam defines t he crit ical workers in each syst em developm ent proj ect , as shown in Figure 5.6. The shaded area of t he figure indicat es t he core t eam . The workers show n wit hin t his area are known as core proj ect workers because t heir responsibilit ies lie in t he crit ical pat h of t he developm ent proj ect . I n ot her words, wit hout t he core w orkers, t he proj ect could not proceed. Ot her im port ant workers whose part icipat ion usually is required in a proj ect are shown st raddling t he edges of t he shaded area. These workers are known as part icipat ing workers because, in general, t hey part icipat e in several t eam s sim ult aneously. Core proj ect w orkers norm ally are allocat ed t o a single t eam . Bot h part icipat ing and core proj ect workers have official work plans in a proj ect . The responsibilit ies of each worker in associat ion wit h his or her role in t he canonical developm ent t eam are present ed below.

-144-

Convergent Architecture

Chapter 5: The IT-Organization Model

Figur e 5 .6 : The canonical developm ent t eam . Two predefined specializat ions of canonical developm ent t eam s exist , as shown in Figure 5.5. These specialt y t eam s are t he ones used in concret e developm ent proj ect s. The canonical developm ent t eam serves as t he basis for bot h t hese t eam s because t hey bot h have t he sam e basic st ruct ure, core w orkers and part icipat ing workers. Assem bly developm ent t eam s focus on t he highly int egrat ive aspect s required t o deliver assem bly com ponent s. Com ponent developm ent t eam s specialize in t he reusable com ponent s t hat t he assem bly owns and m anages. How each specialt y t eam differs from t he canonical developm ent t eam is covered in t he following respect ive subsect ions. I f a proj ect only has one t eam , t hen t his t eam m ust be com prised of t he workers and responsibilit ies of bot h specialt y t eam s.

W or k e r Role s a n d Re spon sibilit ie s ƒ

o o

Worker core roles and responsibilit ies in t he canonical developm ent t eam include t he following: D om a in e x pe r t . This experienced business operat or possesses up- t odat e, pract ical knowledge on t he workings of t he business. He or she accom panies t he proj ect as it s business dom ain " cham pion," m odeler, and advisor t hroughout all phases of t he proj ect t o ensure t he business relevance and correct ness of t he syst em . This person is t he prim ary com m unicat ion channel t o business organizat ions influenced by or influencing t he developm ent of t he com ponent . Due t o ot her business obligat ions, t his worker norm ally cannot part icipat e as a full- t im e t eam m em ber. However, t his worker m ust be int im at ely involved in developm ent and share responsibilit y for success of t he t eam . I n part icular, t he dom ain expert does t he following: Provides rapid, aut horit at ive decisions on t he essent ial and " nice t o have" fut ure requirem ent s of t he dom ain. Develops applied work scenarios covering t he relevant business dom ain, including pot ent ial use scenarios of a new syst em . The

-145-

Convergent Architecture

o o

Chapter 5: The IT-Organization Model

developm ent of scenarios m ay be delegat ed t o ot her dom ain specialist s under t he direct ion of t he dom ain expert . Works wit h t he lead developer t o drive developm ent from t he business perspect ive. Convergent Archit ect ure- specific consolidat ion of t he following RUP worker roles: business designer and use- case specifier. Ow ne d r e sour ce s:

o o ƒ

o

o

o o

o

ƒ ƒ ƒ

ƒ

o ƒ

Cha nge se t s ( a r t ifa ct s) : Business use- case scenarios ( BUCS) and accessor use- case scenarios ( AUCS) . Spe cia lize d t e ch nologie s: C- BOM com ponent s of t he archit ect ural- I DE. Le a d de ve lope r . This is t he single aut horit at ive t echnical leader of t he t eam . I n addit ion t o fulfilling t he role of assem bly developer in t he assem bly developm ent t eam ( discussed lat er) or of com ponent developer in t he com ponent developm ent t eam ( discussed lat er) , t he lead developer is t he principal aut horit at ive t echnical cont act for all part icipat ing t eam workers and ext ernal st akeholders of t he t eam . I n part icular, t he lead developer does t he following: Carries out all design sessions wit h t he dom ain expert t o ensure a concise definit ion of business t erm inology and convergent , business- relevant result s. Works wit h t he convergent archit ect t o consolidat e t he convergent business m odel and t erm inology across all proj ect s and, in general, t o ensure archit ect ural int egrit y across proj ect s. Rem ains resource ow ner of t he respect ive convergent com ponent across all generat ions unt il it is ret ired from use. Defines best - fit CCM change- set s for t he convergent com ponent s t oget her wit h t he convergent archit ect and configurat ion m anager. Convergent Archit ect ure- specific consolidat ion of t he following RUP worker roles: com ponent developer ( discussed lat er) or assem bly developer ( discussed lat er) depending on t he developm ent t eam , plus RUP business designer and RUP code review er. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : See com ponent developer or assem bly developer depending on t he developm ent t eam . Spe cia lize d t e ch nologie s: The ent ire archit ect ural- I DE. Com pone n t de ve lope r . Depending on t he scale of t he proj ect , t here m ay be addit ional com ponent developers as described lat er in t he chapt er in t he com ponent developm ent t eam . There should be a m axim um of six com ponent developers in a single t eam . UI - a cce ssor de ve lope r . This expert in UI - accessor developm ent develops any hum an int erfaces required by a convergent com ponent . This worker is a Convergent Archit ect ure- specific inst ance of t he following RUP worker roles: user- int erface designer, designer, and im plem ent er. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : UI - accessor com ponent ( accessor m odels, docum ent at ion, im plem ent at ion) .

-146-

Convergent Architecture

ƒ ƒ

o ƒ

ƒ

Chapter 5: The IT-Organization Model

Spe cia lize d t e ch nologie s: The com ponent of t he archit ect ural- I DE from C- REF on down. SI - a cce ssor de ve lope r . This expert in accessor developm ent develops any SI - accessors required t o int eract wit h ext ernal ent it ies. A UI accessor developer m ay fill t his worker role because t here m ay be an overlap in developm ent skills. I n addit ion t o underst anding accessor developm ent , t his worker should, at best , already be fam iliar wit h t he t ypes of ext ernal syst em s t hat will be accessed by t he com ponent . This w orker is a Convergent Archit ect ure- specific inst ance of t he following RUP worker roles: designer and im plem ent er. Ow ne d r e sour ce s: Cha nge se t s ( a r t ifa ct s) : SI - accessor com ponent ( accessor m odels, docum ent at ion, m odels, im plem ent at ion) . Spe cia lize d t e ch nologie s: The com ponent s of t he archit ect ural- I DE from C- REF on down.

Pa r t icipa t in g W or k e r s

ƒ

ƒ

The syst em proj ect m anager plans part icipat ing workers in t he sam e way core workers are planned. Two differences exist bet ween part icipat ing and core workers. First , part icipat ing workers m ay not be needed in every proj ect or m ay not be required in each proj ect it erat ion. They are not t he perm anent spearhead of t he crit ical developm ent pat h. I nst ead, t hey part icipat e at different st at ions along t he crit ical developm ent pat h. Second, part icipat ing workers usually provide special services t o several proj ect s in parallel. This cross- proj ect part icipat ion is im port ant t o ensure int egrat ive or " horizont al" synergies and design uniform it y in each highly specialized area. The part icipat ing w orkers are m easured by t he syst em proj ect m anagers concerning t heir individual proj ect cont ribut ions and by t he st eering t eam regarding t heir opt im izing cont ribut ion across all proj ect s in which t hey part icipat e. Each part icipat ing worker cont ribut es as follows t o t he developm ent t eam : Syst e m pr oj e ct m a n a ge r ( pa r t icipa t e s fr om t he syst e m de ve lopm e nt or ga niz a t ion) . This m anager accom panies t he t eam effort as t eam init iat or, planner, organizer, and facilit at or. He or she is t he escalat ion int erface t o t he st eering t eam in t he I T organizat ion. His or her principal goal as part icipant is t o enable t echnical personnel t o opt im ally apply t heir respect ive skills t oward crit ical, m easurable proj ect goals. This is rarely a fullt im e j ob for a properly st affed proj ect . Conve r ge n t a r chit e ct ( pa r t icipa t e s fr om t h e a r chit e ct ur e or ga niz a t ion) . The convergent archit ect consult s t he syst em proj ect m anager and lead developer on proj ect and it erat ion planning act ivit ies. He or she is a design coach and reviewer who norm ally is assigned t o t hese act ivit ies at t he beginning and end of each proj ect it erat ion. He or she assesses and enforces int raproj ect qualit y t hrough reviews and consult ing and ensures int erproj ect qualit y t hrough parallel part icipat ion in m any proj ect s. This worker also ensures t im ely feedback regarding qualit y and opt im izat ion pot ent ial of t he archit ect ural st yle. The convergent archit ect also m ay spend considerable t im e as a coach and codeveloper w it hin a single t eam .

-147-

Convergent Architecture

ƒ

ƒ ƒ ƒ

ƒ

ƒ

ƒ

Chapter 5: The IT-Organization Model

D e ve lopm e nt t oolsm it h ( pa r t icipa t e s fr om t h e syst e m de ve lopm e nt or ga niz a t ion) . This worker helps t eam m em bers configure and t une t he archit ect ural- I DE and ot her t ools t o t he requirem ent s of a specific proj ect . Gr a ph ic a r t ist ( pa r t icipa t e s fr om t he pr oj e ct infor m a t ion, e ve nt s, a nd t r a ining or ga niz a t ion) . This worker develops proj ect - specific art work. This art work norm ally is associat ed direct ly wit h t he convergent com ponent . Com put e r e r gon om ics a nd GUI e x pe r t ( pa r t icipa t e s fr om t he pr oj e ct infor m a t ion, e ve nt s, a nd t r a ining or ga niza t ion) . This worker assist s t he UI - accessor developer wit h represent er design and developm ent . Educa t or ( pa r t icipa t e s fr om t he pr oj e ct in for m a t ion, e ve nt s, a nd t r a inin g or ga niz a t ion ) . This worker helps assess t raining needs in t he init ial planning st ages of t he proj ect . This includes bot h t he t raining needs of t he proj ect t eam and t raining for end users of t he developed syst em . He or she arranges t he t im ely educat ion of t eam . m em bers, develops end- user t raining wit h t he t echnical w rit er, and coordinat es t he delivery of t raining wit h t he dom ain expert and deploym ent m anager. Te chnica l w r it e r ( pa r t icipa t e s fr om t he pr oj e ct infor m a t ion, e ve nt s, a nd t r a ining or ga niza t ion ) . This worker plans and com piles bot h design and user docum ent at ion. He or she also m ay produce educat ional m at erials. This includes ensuring t hat ot her t eam m em bers underst and t heir responsibilit ies as cont ribut ors t o qualit y docum ent at ion. For exam ple, welldocum ent ed m odels, in- code docum ent at ion, and usage sam ples are produced by developers for docum ent at ion, not produced from scrat ch by t he t echnical writ er. I n t he course of creat ing high- qualit y docum ent at ion, t he t echnical writ er verifies t he accuracy of t he docum ent s and sam ples and provides cont inuous feedback t o t he developers. Te st m a n a ge r ( pa r t icipa t e s fr om t h e t e st ce n t e r or ga n iza t ion ) . This worker plans, designs, and coordinat es proj ect - specific t est ing wit h t he lead developer. He or she provides each com ponent developer wit h clear t est abilit y requirem ent s and inst ruct ions for individual t est ing responsibilit ies such as unit t est ing. D e ploym e nt m a na ge r ( pa r t icipa t e s fr om ope r a t iona l syst e m s or ga niz a t ion) . This worker cont ribut es proj ect - specific requirem ent s from t he operat ional syst em s organizat ion, including deploym ent , t ransit ion, and educat ion aspect s. He or she w orks wit h t he syst em proj ect m anager and lead developer t o ensure fulfillm ent of t hese requirem ent s early on in t he proj ect and coordinat es and carries out operat ional deploym ent t est s and t he operat ional t ransit ion. The Asse m bly D e ve lopm e nt Te a m The assem bly developm ent t eam specializes in t he highly int egrat ive aspect s required t o deliver an operat ional assem bly com ponent . Figure 5.5 shows t hat com ponent developm ent t eam s operat e in t he cont ext of a single assem bly developm ent t eam . This is so because t he assem bly com ponent encapsulat es and exclusively m anages convergent com ponent s. The assem bly developm ent t eam , in part icular t he lead developer of t he t eam , is t he resource owner of t he assem bly

-148-

Convergent Architecture

Chapter 5: The IT-Organization Model

com ponent , and t he lead developer of t he respect ive com ponent developm ent t eam is t he resource owner of it s convergent com ponent s. Any developm ent t eam s out side t he cont ext of t he assem bly m ust coordinat e design changes t o t he convergent com ponent s wit h t heir respect ive resource owners. The assem bly developm ent t eam m ay m anage several com ponent developm ent t eam s. Alt ernat ively, at t he discret ion of t he assem bly developm ent t eam , a single com ponent developm ent t eam m ay develop m ore t han one of it s convergent com ponent s. As discussed in Chapt er 4, an assem bly m ay be com prised of accessor com ponent s t hat are part icular t o t he assem bly but not uniquely associat ed wit h any single com ponent wit hin t he assem bly. The assem bly developm ent t eam norm ally develops such accessors. Many assem bly com ponent s m ay exist in various st ages of developm ent or deploym ent at any t im e in t he syst em developm ent organizat ion. The lead developer of each assem bly com ponent rem ains it s resource ow ner t hroughout it s ent ire life cycle and accom panies it s evolut ion t hrough generat ions of developm ent and deploym ent .

W or k e r Role s a n d Re spon sibilit ie s ƒ

o

o

o

o o

o

o

Worker- specialized roles and responsibilit ies in t he assem bly developm ent t eam include t he following: Asse m bly de ve lope r . This is t he lead developer of t he assem bly developm ent t eam who norm ally has ext ensive experience as a com ponent developer. This worker has t he following addit ional responsibilit ies as ow ner of t he assem bly com ponent : Begins wit h t he incept ion phase of a developm ent proj ect t o delim it and define t he proj ect and help t he syst em proj ect m anager produce t he longt erm developm ent st rat egy. Develops t he BUCS, AUCS, and t he convergent business obj ect m odel for t he ent ire assem bly t oget her wit h t he dom ain expert s involved in t he assem bly. Works in t he proj ect planning st ages t o define t he com ponent developm ent t eam s required by t he assem bly, part it ions developm ent am ong t he t eam s, and works closely wit h t he lead developers of t hese t eam s. Develops t he assem bly- specific configurat ion m anagem ent reference t oget her wit h t he lead developers and configurat ion m anager. Produces t he assem bly archit ect ure reference, which describes t he overall design of t he assem bly in t he cont ext of t he Convergent Archit ect ure st yle reference. The assem bly archit ect ure reference consolidat es t he com ponent design references produced by it s com ponent developm ent t eam s. Defines, im plem ent s, and carries out int egrat ion t est s, business- case t est s, and inst allat ion and deploym ent t est s for t he ent ire assem bly. Assem bly t est s are carried out in t he t est cent er organizat ion assist ed by it s respect ive workers. Defines and carries out t he deploym ent plan for t he assem bly wit h t he deploym ent m anager. The deploym ent plan covers bot h t est s and operat ional releases.

-149-

Convergent Architecture

o o

o

o o

Chapter 5: The IT-Organization Model

Develops t he assem bly inst allat ion kit , which drives t he int elligent inst allat ion and deploym ent of t he assem bly. Coordinat es t he developm ent of design and end- user docum ent at ion wit h t he t echnical writ er and t he com ponent developm ent t eam s. Coordinat es and t racks t he reuse of any of it s enclosed convergent com ponent s by ot her assem blies. This t racking inform at ion is recorded in t he assem bly m odels. By t he sam e t oken, he or she com m unicat es t he reuse of ext ernal convergent com ponent s wit h t he respect ive assem bly developer. Rem ains resource ow ner of t he assem bly across all generat ions unt il it is ret ired from use. Convergent Archit ect ure- specific consolidat ion of t he following RUP worker roles: sam e as com ponent developer ( discussed lat er) plus RUP syst em analyst and RUP int egrat or. Ow ne d r e sour ce s:

o

o

o

o

o

Cha nge se t s ( a r t ifa ct s) : Assem bly com ponent ( assem bly archit ect ure reference, assem bly glossary, assem bly configurat ion m anagem ent reference, archit ect ural I DE art ifact s [ convergent business obj ect m odel, assem bly UML m odel, proj ect configurat ion files, generat ion cart ridges, build and t est environm ent , Java- I DE environm ent ] , assem bly inst allat ion kit , user docum ent at ion, developer docum ent at ion, applicat ion server configurat ion) . The following specificat ions apply: The convergent business obj ect m odel is com prised of t he st ruct ural CRC m odel and dynam ic st at e- t ransit ion- flow m odels ( visual and recorded run- t hroughs) of BUCS and AUCS. The assem bly UML m odel is com prised of t he cum ulat ive accessor com ponent m odels and business com ponent m odels ( opt ional UML represent at ions as required for explanat ory or docum ent at ion det ail: use- case represent at ions of BUCS and AUCS, sequence diagram s, and act ivit y diagram s for convergent com ponent s) . The assem bly inst allat ion kit norm ally deploys an ent erprise archive ( EAR) in t he J2EE t echnology proj ect ion and is com prised of all convergent com ponent inst allat ion set s ( discussed lat er) , J2EE Web archives cont aining accessors, EJB archives, client Java archives, uninst aller, consolidat ed user docum ent at ion, assem bly inst allat ion guide and release not es, and t he consolidat ed inst allat ion verificat ion t est . Spe cia lize d t e ch nologie s: Sam e as Lead Developer plus Zero- G I nst all Anywhere. The Com pone nt D e ve lopm e nt Te a m Com ponent developm ent t eam s specialize in t he reusable part s of assem blies. Alt hough t he convergent com ponent s will be m anaged exclusively by t heir owning assem bly, t hey oft en will be reused by ot her assem blies. [ 5] Thus, t he com ponent developm ent t eam plays an im port ant role in producing effect ively reusable convergent com ponent s.

-150-

Convergent Architecture

Chapter 5: The IT-Organization Model

W or k e r Role s a n d Re spon sibilit ie s

o

o

o o o

AM FL Y

o

Ow ne d r e sour ce s: o

o

o

TE

ƒ

Worker- specialized roles and responsibilit ies in t he com ponent developm ent t eam include t he following: Com pone n t de ve lope r . This worker is a developer in t he cont ext of t he com ponent developm ent t eam . A com ponent developer m ay be designat ed as t he lead developer of t he com ponent developm ent t eam , in which case he or she is t he definit ive owner of t he following specific responsibilit ies as well as t he responsibilit ies of t he lead developer described earlier. I f not designat ed as t he single lead developer in t he t eam , t hen t he com ponent developer works under t he direct ion of t he lead developer t o help fulfill t hese responsibilit ies: Furt her refines t he convergent business obj ect s allocat ed t o t he com ponent developm ent t eam by t he assem bly developer int o deployable convergent com ponent s. This includes m odel refinem ent , t echnical m odeling, m odel- driven im plem ent at ion, and t est ing of t he com ponent s. Defines art ifact part it ioning ( for exam ple, UML m odels, Java archives, Java packages, and docum ent at ion) wit h t he assem bly developer t o ensure effect ive consolidat ion of t hese art ifact s int o t he assem bly com ponent . Refines t he accessor use cases specific t o t he assigned convergent com ponent s t oget her wit h t he dom ain expert and defines and drives accessor developm ent . Develops t he convergent com ponent inst allat ion set for t he com ponent in conj unct ion wit h t he assem bly developer. Works wit h t he t echnical w rit er t o creat e design and user docum ent at ion m at erials. Convergent Archit ect ure- specific consolidat ion of t he following RUP worker roles: t est designer, developer, capsule developer, im plem ent er, dat abase designer.

Cha nge se t s ( a r t ifa ct s) : Convergent com ponent s ( archit ect ural- I DE art ifact s [ UML m odels, configurat ion files, generat ion cart ridges, build and t est environm ent s, Java- I DE environm ent s, proj ect configurat ion files] , com ponent inst allat ion set s, user docum ent at ion m at erials, developer docum ent at ion) . The following specificat ions apply: The com ponent inst allat ion set for t he J2EE t echnology proj ect ion ( Chapt er 8) com prises: J2EE WebArchives cont aining accessors, EJB archives, client archives, and an inst allat ion verificat ion t est . Spe cia lize d t e ch nologie s: Sam e as lead developer. [ 4]

This is a st yle- specific applicat ion of t he concept s form ulat ed in t he RUP Work Guideline, "Developing Large- Scale Syst em s wit h t he Rat ional Unified Process" ( Krucht en 2000) .

[ 5]

Not e t hat an assem bly is an organizat ion from a purely I T perspect ive. I t organizes deployable I T resources. I t does not represent a core business organizat ion and is assigned t his special nam e t o m ake t his dist inct ion clear.

-151-

Team-Fly®

Convergent Architecture

Chapter 5: The IT-Organization Model

Th e Ope r a t ion a l Syst e m s Or ga n iz a t ion The operat ional syst em s organizat ion ( OPS- O) is where assem blies are deployed and put int o operat ional use. The specialt y and prim e responsibilit y of t his organizat ion is t o provide a robust , st able environm ent as specified by t he assem bly developm ent t eam s in t he assem bly inst allat ion guide. The assem bly, including it s operat ional inst allat ion, is developed in conj unct ion w it h t he operat ional syst em s organizat ion ( deploym ent m anager) t o ensure feasibilit y and realist ic expect at ions of all st akeholders regarding deploym ent , t est , m aint enance, and long- t erm operat ion of t he assem bly. The chief archit ect works wit h t he operat ional syst em s organizat ion t o ensure t hat t he sim plest possible operat ional environm ent evolves t o fulfill t he diverse requirem ent s of assem blies. The operat ional syst em s organizat ion also exist s when t he I T organizat ion is developing soft ware t o be sold t o ext ernal cust om ers. The only difference is t he focus on ext ernal cust om ers in cont rast t o int ernal cust om ers. The operat ional needs of t hese t wo cust om er groups are essent ially ident ical from t he perspect ive of t he I T organizat ion. I n t he case of ext ernal cust om ers, t he t ransit ion organizat ion described lat er m anages prerelease t est s ( bet a- t est program s) and t he rapport wit h cust om ers during t he t ransit ion phase of syst em developm ent . I n parallel, it channels t he rollout of t he soft ware product t o t he respect ive m arket ing, sales, and dist ribut ion organizat ions. Wit h regard t o t he ot her organizat ions described in t he chapt er, t he user support organizat ion becom es t he cust om er support organizat ion and t he local infrast ruct ure and base syst em s organizat ion provides necessary base syst em s for t hese act ivit ies. The feedback channels and relat ionships wit h t he ot her I T organizat ions rem ain unchanged. As indicat ed in Figure 5.7, t he operat ional syst em s organizat ion is part it ioned int o four suborganizat ions. All it s responsibilit ies and roles, aside from t hose com m on t o every I T organizat ion, are delegat ed t o t he suborganizat ions, w hich are covered individually in t he following subsect ions.

Figur e 5 .7 : The operat ional syst em s organizat ion. The Tr a nsit ion Or ga niza t ion The t ransit ion organizat ion ( Transit ion- O) is concerned w it h effect ively m oving assem blies int o t he operat ional environm ent . Such m ovem ent s m ay occur not only at t he end of t he developm ent cycle, but also at t he end of it erat ions during elaborat ion and const ruct ion of an assem bly. This organizat ion is responsible for reducing im pedance and frict ion bet ween t he developm ent phases of t he syst em 's life cycle and t he operat ional phases of it s life cycle. To achieve t his, t he t ransit ion organizat ion is involved in t he ent ire life cycle of t he syst em t o ensure com pat ible

-152-

Convergent Architecture

Chapter 5: The IT-Organization Model

planning and developm ent of capabilit ies in bot h syst em developm ent and operat ional syst em s organizat ions.

W or k e r Role s a n d Re spon sibilit ie s ƒ

Worker roles and responsibilit ies in t he operat ional syst em s organizat ion include t he following: D e ploym e nt m a na ge r ( pa r t icipa t e s in ca nonica l de ve lopm e nt t e a m ) . This I T operat ions expert works in t he cont ext of syst em developm ent proj ect s t o ensure t hat t he requirem ent s of t he operat ional environm ent are m et . This includes such aspect s as infrast ruct ure, inst allat ion, t est ing, t raining, adm inist rat ion, and upgrades. He or she also coordinat es and m anages t he t ransit ion t est s and final operat ional t ransit ion of an assem bly. This worker is a Convergent Archit ect ure- specific inst ance of t he following RUP worker role: deploym ent m anager. The Use r Suppor t Or ga niza t ion The user support organizat ion ( UserSupport - O) provides professional front - line support t o end users of assem blies.

W or k e r Role s a n d Re spon sibilit ie s ƒ

o o o ƒ

Worker roles and responsibilit ies in t he user support organizat ion include t he following: Use r suppor t spe cia list . This worker is an experienced user of t he assem bly and has been t rained t o ensure an effect ive w ork environm ent for end users of t he assem bly. He or she fulfills t he following specific responsibilit ies: Set s up and configures t he end- user environm ent for an inst alled assem bly. Provides everyday front - line user support and hot - line services. The single escalat ion int erface for end- users t o t he syst em developm ent organizat ion and t he assem bly developer. He or she provides change request s and feedback t o t he requirem ent s m anager. End- use r e duca t or . This experienced user support specialist is responsible for t raining groups of new assem bly end- users. The t rainings are organized wit h and coordinat ed by t he proj ect inform at ion, event s, and t raining organizat ion. The I nfr a st r uct ur e a nd Ba se Syst e m s Or ga niza t ion Com m ensurat e wit h t he infrast ruct ure and base syst em s organizat ion in t he I T support organizat ion, t he operat ional infrast ruct ure and base syst em s organizat ion ( OPS- I nfraBas- O) is responsible for support ing t he operat ional syst em s organizat ion. An operat ions- specific organizat ion is required because t he priorit ies and const raint s of t he operat ional environm ent differ significant ly from t hose of t he developm ent environm ent . For exam ple, securit y, availabilit y, and m igrat ion aspect s play a m uch m ore significant role in t he operat ional environm ent t han t hey do in t he developm ent environm ent .

-153-

Convergent Architecture

Chapter 5: The IT-Organization Model

The chief archit ect defines t he com m on- denom inat or operat ional environm ent s t oget her wit h t his organizat ion. The infrast ruct ure and base syst em s organizat ion t hen im plem ent s and support s t he environm ent for t he operat ional syst em s organizat ion. Cont inuit y and consist ence wit h t he I T support organizat ion are m aint ained t hrough frequent , it erat ive proj ect int eract ion in t he course of syst em developm ent proj ect s and t he act ivit ies of t he t est cent er organizat ion.

W or k e r Role s a n d Re spon sibilit ie s ƒ ƒ

ƒ

Worker roles and responsibilit ies in t he infrast ruct ure and base syst em s organizat ion include t he following: OPS syst e m a dm inist r a t or . This worker is t he operat ional count erpart t o t he syst em adm inist rat or in t he I T support organizat ion. Cont a ine r ope r a t or . The cont ainer operat or t akes up w here t he OPS syst em adm inist rat or leaves off. He or she is a specialist in a specific t ype of applicat ion server cont ainer and m anages t his environm ent in t he int erest of all deployed assem blies and t heir users. This includes professional m anagem ent of t he underlying dat a st ores ( dat abases) and proact ive perform ance m anagem ent such as clust ering and load balancing. For t he J2EE/ EJB t echnology proj ect ion, t his worker inst alls and m anages a dist ribut ed J2EE/ EJB cont ainer environm ent , including it s associat ed dat abases. This worker also provides t im ely feedback on cont ainer- specific t uning requirem ent s t o t he deploym ent m anager and t he requirem ent s m anager. Asse m bly ope r a t or . Assem blies m ay be ext ensive, heavily used, and widely dist ribut ed. The assem bly operat or com plem ent s t he cont ainer operat or in large inst allat ions t o ensure proper adm inist rat ion, m aint enance, and t uning of a specific assem bly in t he operat ional environm ent . This worker also carries out assem bly- specific act ivit ies in t he operat ional environm ent such as online m onit oring, securit y m anagem ent , problem t racing, and infrast ruct ure m igrat ion. He or she works closely w it h t he cont ainer operat or and provides feedback regarding operat ional im provem ent s t o t he assem bly developer, deploym ent m anager, and requirem ent s m anager.

Su m m a r y A properly prepared I T organizat ion is fundam ent al t o producing effect ive I T syst em s. Above all, a well- t uned organizat ion sim plifies t hings by adding cont inuit y and order t o t he const ant ly m oving landscape of developm ent act ivit ies, workers, and art ifact s involved in syst em developm ent . The I T- organizat ion m odel present ed in t his chapt er defined such a w ell- t uned organizat ion. I t described a reference organizat ion t hat has been st ream lined t o support large- scale syst em developm ent according t o t he archit ect ural st yle. The effect iveness of t his reference organizat ion st em s from t he fact t hat it is sensit ive t o t he st yle of syst em s t hat will be built . As such, it can be m ore specific about t he resources, processes, and t ools used t o creat e t hese syst em s. I n t his chapt er, t he basic OPR concept s present ed in Chapt er 3 were used t o st ruct ure t he I T organizat ion and t o define t he roles and responsibilit ies of w orkers in t he cont ext of concret e organizat ions. I n addit ion, t he art ifact s creat ed by t hese workers were specified along wit h any specialized t ools t hese workers use t o produce and m anipulat e t hese art ifact s. The reference I T organizat ion m ay be used as a basis t o prepare I T organizat ions, large or sm all, t o consist ent ly produce syst em s according t o t he Convergent

-154-

Convergent Architecture

Chapter 5: The IT-Organization Model

Archit ect ure. I t also set s t he st age t o present t he process—t he specific flow of act ivit ies bet ween workers, t ools, and art ifact s. This flow of act ivit ies wit hin t he I T organizat ion is t he focus of t he process m odel in t he next chapt er.

-155-

Convergent Architecture

Chapter 6: The Development Process

Ch a pt e r 6 : Th e D e ve lopm e n t Pr oce ss M ode l Ove r vie w The preceding chapt er addressed t he design of t he inform at ion t echnology ( I T) organizat ion. This chapt er will focus on t he developm ent process m odel, also referred t o as t he Convergent Archit ect ure ( CA) process, t hat com plem ent s and leverages t he responsibilit ies, workers, and art ifact s of t he I T organizat ion. This is t he t hird and last com ponent in t he developm ent m odel of t he Convergent Archit ect ure. The exist ence of hundreds of books covering t he soft w are process is clear evidence of t he cent ral im port ance of t his process in professional soft ware organizat ions. Alt hough t here is am ple discord—wit h a t ouch of religious fanat icism —as t o which precise approach is best , m any of t he m odern m et hodologies exhibit m ore sim ilarit ies t han differences. Their principal differences lie in t he st ruct ure of t heir present at ion, t heir weight ing or em phasis of part icular process aspect s, and t heir scope. I ndeed, t here is no precise definit ion of where process begins and w here it leaves off. This is why t he Convergent Archit ect ure sees process as j ust one aspect of a holist ic approach t hat addresses t he t hree pillars of proj ect design, business design, and syst em design. The CA process is not yet anot her generalized developm ent process or m et hodology. As you w ill see in t he follow ing sect ion, t he CA process refines aspect s of exist ing m et hodologies. However, inst ead of t aking a process- cent ric approach, it t akes a st yle- cent ric approach: I t considers process in t he cont ext of t he rest of t he archit ect ural st yle. By doing t his, feat ures of t he archit ect ure can be t uned t o assist each ot her in all direct ions. This is in st ark cont rast t o m any m et hodologies t hat expend considerable effort t rying t o m ake t hings w ork t oget her t hat were not designed t o work t oget her. I n ot her words, in t he developm ent of t he CA process, t wo quest ions are of m ain concern. First , how can t he CA process help us achieve our st yle- specific goals using t he ot her feat ures of t he st yle—t he organizat ion m odel, t he convergent com ponent m et am odel, t he archit ect ural int egrat ed developm ent environm ent ( I DE) , and so fort h? Second, and m ost im port ant , how can t he ot her feat ures of t he st yle help us sim plify t he CA process? The answers t o t hese quest ions result s in a cont inuous fine- t uning from t he perspect ives of bot h t he developm ent process and it s surrounding environm ent . Such com prehensive opt im izat ion from various perspect ives enables efficiencies and synergies not possible from a unidirect ional, process- cent ric perspect ive. This m ult idirect ional t uning cont ribut es t o what I call reference- fram e cont inuit y, an int rinsic propert y of t he archit ect ural st yle: Every proj ect benefit s from it aut om at ically and im m ediat ely. Before m oving int o t he det ails, let 's look at one exam ple of reference- fram e cont inuit y and how it sim plifies t he CA process. A good exam ple is t he int eract ion bet ween t he m odeling st yle and t he archit ect ural I DE, which, alt hough not t hem selves part of t he CA process, are part of t he st yle. As such, t hey are a dependable part of a reference fram e t hat can be leveraged by ot her part s of t he st yle. I n t his part icular exam ple, t he archit ect ural I DE and t he m odeling st yle com bine forces t o sim plify several workflows, t hus sim plifying t he CA process. Based on t he m odeling st yle, t he I DE can act ively assist t he developer t hrough m any act ivit ies. [ 1] I n m any sit uat ions, t he developer only needs t o set a few key

-156-

Convergent Architecture

Chapter 6: The Development Process

propert ies in t he m odel t o enable t he I DE t o aut om at ically derive ot her m odels and propert ies. These derived design feat ures are lat er used by t he I DE t o generat e source code, also according t o t he m odeling st yle. I n such cases, t he developer can be successful wit hout having an expert background and/ or having ext ensive experience wit h t hese act ivit ies. For exam ple, during accessor developm ent , com plex design m echanism s such as user event dispat ching or t he int eract ion bet ween t he fram es of an I nt ernet represent er are now carried out in t he cont ext of assist ed m odeling. As such, t hese aspect s no longer need t o be handled in t he workflow descript ion. They are delegat ed t o t he st yle- specific I DE. This new level of assist ance and aut om at ion const it ut es a logical st ep t oward higher design capabilit ies sim ilar t o t he im provem ent s brought about by t hird- generat ion com pilers. Just as no ot her developm ent processes would describe t he int ernal workings of a com piler as part of t he workflow, t he workflow s of t he CA process do not need t o cover t he aspect s handled aut om at ically by it s archit ect ural I DE. From t he perspect ive of t he developer, t he com plexit y disappears ( wit hout being ignored by t he archit ect ure) , and t his aspect of developm ent becom es a sim ple st ep in t he workflow descript ion. Let 's now look at t he foundat ions and basic st ruct ure of t he CA process before det ailing each of it s workflows in a separat e sect ion. [ 1]

I refer t o t his as st yle- driven assist ed m odeling.

Fou n da t ion s a n d St r u ct u r e As shown in Figure 6.1, t he CA process is an archit ect ural- st yle- specific inst ance of t he Rat ional Unified Process ( RUP) ( Krucht en 1998) . However, t he RUP is only one of t he m odern m et hodologies t hat has influenced t he CA- specific process t hroughout it s evolut ion. The figure shows t he ot her m aj or cont ribut ors from which t he CA process was derived. I t also indicat es t he progression t hat t ook place over t he years. The m aj or players in t his progression are explained below t he figure.

Figur e 6 .1 : A specific inst ance of process archit ect ures. CA's relat ionship t o t hirdgenerat ion SW process fram eworks. The lines in t he figure illust rat e t he process of com bining and filt ering several m et hodologies over t he years t o form t he CA process as it st ands t oday. I t begins at t he left wit h a very broadly scoped soft ware engineering process archit ect ure

-157-

Convergent Architecture

ƒ

ƒ

ƒ

ƒ

Chapter 6: The Development Process

( Graham 1997) . The m et hodologies in t he cent er of t he figure are m ore specific, each having it s own specific focus, st rengt h, and scope. Consolidat ed part s of t hese m et hodologies flow int o a CA- specific inst ance shown at t he right . Along t he way, each of t hese st ream s is int egrat ed and configured t o best fulfill t he principles and requirem ent s from t he ot her m odels of t he archit ect ural st yle. Moving from left t o right , t he cont ribut ing m et hodologies and t heir relat ionships from t he perspect ive of t he CA process are as follows: The OPEN Pr oce ss Spe cifica t ion ( OPEN ) ( Gr a ha m 1 9 9 7 ) . This is known as a t hird- generat ion m et hodology because it focuses on m odern concept s such as t he obj ect paradigm , m et am odels, and pat t erns in soft w are developm ent . This includes part icular em phasis on t he principles of convergent engineering, including responsibilit y- driven design ( RDD) and analysis by design ( ABD) . The direct line bet ween OPEN and t he CA process indicat es t hat t he OPEN concept s were a m ainst ream basis for t he CA process before being lat er influenced by RUP and cat alysis. The Ra t ion a l Unifie d Pr oce ss ( RUP) ( Kr ucht e n 1 9 9 8 ) . Alt hough not a direct derivat ive of OPEN, RUP com plem ent s and refines m any concept s found in OPEN. I n addit ion t o it s different weight ing of cert ain concept s, RUP adds st ruct ural clarit y and pert inent m anagem ent - level explanat ions of t he m odern developm ent process. I n part icular, RUP recognizes and explains t he im port ance of process inst ances and is designed t o serve as a basis for such inst ances. This is one reason it is used as t he foundat ion for a CA- specific inst ance. The e volut iona r y pr oj e ct m a na ge m e nt ( EPM ) m e t h od ( Gilb 1 9 8 8 / 1 9 9 9 ) . Alt hough not based on RUP, EPM w as found t o com plem ent RUP wit h pragm at ic proj ect - m anagem ent feat ures. The EPM feat ures t hat m ost influenced t he CA process were in t he area of evolut ionary t eam building and evolut ionary developm ent , im plicit requirem ent s m anagem ent , im plicit qualit y cont rol, it erat ion planning, and t eam configurat ion. The ca t a lysis a ppr oa ch ( D ' Souz a 1 9 9 8 ) . This reflect s m any of t he concept s found in OPEN or RUP and adds it s ow n part icular em phasis in t he area of com ponent - cent ric developm ent and com ponent design pat t erns. I t also addresses t he UML Obj ect Const raint Language ( OCL 1999) as a sem iform al m eans of specifying design const raint s as a com plem ent t o t he fundam ent al UML not at ion. The CA process at t he right of t he figure em phasizes t hat t hese cont ribut ors influenced aspect s in all t hree pillars of t he Convergent Archit ect ure. As such, t he influence is not localized t o t he CA process but is also evident in t he ot her feat ures of t he archit ect ural st yle. The following subsect ion int roduces t he st ruct ure and cont ent of t he CA process. Ove r vie w : W or k flow s a n d I D E Suppor t To achieve t he goals of t he Convergent Archit ect ure, RUP is st ream lined—as is fit t ing when creat ing an inst ance of RUP. Som e aspect s of RUP are repart it ioned or weight ed different ly. As set fort h by RUP, t he CA process com prises workflows t hat are subdivided and det ailed in t he form of act ivit ies. Sim ilar t o RUP- based workers and art ifact s in t he I T organizat ion, t he w orkflows in t he CA process are derived from corresponding RUP workflow s. Then adapt at ions are m ade according t o t he m odels of t he archit ect ural st yle. No aspect addressed by RUP has been left out , but aspect s m ay be im plicit ly or explicit ly handled elsewhere in t he archit ect ural

-158-

Convergent Architecture

Chapter 6: The Development Process

st yle. As point ed out in t he int roduct ion, t here is no reason t o explain an act ivit y t hat has been t aken care of im plicit ly or aut om at ically elsewhere in t he st yle. A case in point : Many of t he act ivit ies in t he RUP environm ent workflow correspond t o responsibilit ies in I T organizat ion in t he Convergent Archit ect ure. This is because t he I T organizat ion is a separat e m odel in t he Convergent Archit ect ure; it is t he ent ire environm ent of t he CA process, and it is not a w orkflow. Workflows in t he CA process define act ivit ies above and beyond t he responsibilit ies of t he I T organizat ion. These are act ivit ies t hat can be well defined t o enhance t he responsibilit ies of t he I T organizat ion; however, t hey do not replace t he I T organizat ion. The I T- organizat ion m odel exist s t o handle t he m yriad im port ant aspect s of soft ware developm ent t hat cannot , and should not , be defined as an explicit workflow or act ivit y. [ 2] As explained in t he preceding chapt er, RUP w orkflows and act ivit ies denot e hierarchies of processes. I have already defined t he concept of a process in t he Convergent Archit ect ure. Applying t his definit ion in t he cont ext of t his inst ance of t he RUP, workflow s and act ivit ies com plem ent t he ongoing responsibilit ies of t he I T organizat ions by defining and nam ing goal- orient ed set s of t asks. These t asks describe how specific aspect s of t he I T organizat ions and t heir respect ive resources are used t o produce m ore valuable resources. Last ly, t he CA process considers t he m ult iproj ect scope of an ent ire I T organizat ion, no m at t er how ext ensive t his organizat ion m ay be. This is im port ant because t oday's I T landscapes consist of m any dist ribut ed cont ribut ors across m any organizat ions and proj ect s. I n addit ion, significant opt im izat ions due t o an archit ect ural st yle occur at t he cross- proj ect , cross- syst em , and cross- organizat ion levels. For exam ple, t he workflows in t he CA process describe how we use inform at ion gained in one proj ect t o opt im ize bot h t he design and developm ent workflows across ot her proj ect s. I t covers how proj ect s com e and go in t he norm al course of t he overall workflow cycle or how proj ect s drive t heir own reconfigurat ion in t he int erest of business opt im izat ion. Here again, m uch of t his happens t hrough int eract ion wit h t he I T- organizat ion m odel.

ƒ ƒ

ƒ ƒ

To achieve t his, t he workflows in t he CA process are part it ioned int o t wo m aj or cat egories: Pr e pa r a t or y a n d cr oss- pr oj e ct w or k flow s. These workflows are not associat ed wit h any part icular proj ect . They are init iat ed before t he first developm ent proj ect and act in a cross- funct ional m anner across all proj ect s. Ca nonica l pr oj e ct w or k flow s. Sim ilar t o t he canonical developm ent t eam present ed in Chapt er 5, t he canonical proj ect w orkflow describes t he developm ent process used by t he canonical developm ent t eam . I dist inguish here bet ween t wo cat egories of workflows: Cr it ica l- pa t h w or k flow s. These const it ut e t he m ain, essent ial t hread of t he developm ent effort . Wit hout t hese workflows, we w ould not require t he support ing workflows. Su ppor t in g w or k flow s. These are t angent ial t o t he crit ical pat h and, as such, receive less st yle- specific at t ent ion t han t he crit ical- pat h workflows in t his book. The reduced at t ent ion is necessary t o m aint ain proper focus on t he archit ect ural st yle. For support ing workflows in part icular, I refer t o t he guidelines and exam ples provided on t he Convergent Archit ect ure Web sit e. The support ing workflows are labeled as such in t his chapt er.

-159-

Convergent Architecture

Chapter 6: The Development Process

The following sect ions are breakdowns of t hese cat egories. Each sect ion cont ains a sum m ary descript ion of t he workflows in t he cat egory. I t also list s which aspect s of t he archit ect ural I DE are used t o support each act ivit y.

Pr e pa r a t or y a n d Cr oss- Pr oj e ct W or k flow s ƒ

ƒ

ƒ ƒ

ƒ ƒ ƒ ƒ

The I T organizat ion begins business by init iat ing t he following w orkflows: I T- e nvir on m e nt w or k flow . This boot st raps and m aint ains t he I T organizat ion. The I T- organizat ion m anager develops an I T- organizat ion m odel t ailored t o t he specific sit uat ion based on t he m odel described in Chapt er 5. He or she t hen im plem ent s t he m odel by populat ing each of t he I T organizat ions and preparing each organizat ion t o fulfill it s responsibilit ies. The ext ent , speed, and scale of t his preparat ion are det erm ined by t he t w o cross- proj ect workflows indicat ed below t hat define syst em developm ent proj ect s, t heir ext ent , t heir t raining requirem ent s, and so on. Act ivit y ow n e r s. I T- organizat ion m anager. Spe cia lize d t e chnologie s. None. T- ba r busine ss m ode ling a n d r e quir e m e nt s w or k flow . This m anages t he t op level of an overall analysis- by- design workflow ( see t he following sect ion) according t o t he T- t echnique as unanim ously endorsed by convergent engineering ( Taylor 1995) , Microsoft ( Am bler 1997) , and RUP ( Krucht en 2000) . This w orkflow applies t he responsibilit y- driven design ( RDD) concept s as form ulat ed by convergent engineering and RUP's " Work Guidelines: Role Playing" ( Rat ional 2000) . Act ivit y ow n e r s. Chief archit ect , I T- organizat ion m anager, requirem ent s m anager. Spe cia lize d t e chnologie s. Archit ect ural I DE, prim arily t he C- BOM m odule; Visio ( or equivalent ) . Ar chit e ct ur a l e volut ion w or k flow . This evolves, refines, adapt s, and m aint ains t he organizat ion- specific inst ance of t he Convergent Archit ect ure. Act ivit y ow n e r s. Chief archit ect .

ƒ

Spe cia lize d t e chnologie s. Archit ect ural I DE.

Ca n on ica l Pr oj e ct W or k flow s

ƒ

Assem bly and com ponent developm ent t eam s proceed hand in hand as described in t he preceding chapt er. They are logical subdivisions, each producing part s of one unit , t he assem bly. Each assem bly developm ent t eam has m uch in com m on wit h t he com ponent developm ent t eam ; t hey j ust have a different focus w hile m oving along a sim ilar pat h t oward a com m on goal. For t his reason, a canonical proj ect workflow also corresponds t o t he canonical proj ect t eam and it s variant s defined in t he I T- organizat ion m odel. I n t he descript ion of canonical proj ect workflows, t he act ivit ies of t he w orkers in bot h assem bly and com ponent developm ent t eam s are point ed out as we st ep t hrough t he workflow. Whet her a part icular act ivit y applies specifically t o an assem bly or com ponent developm ent t eam is clear by t he worker designat ed as t he act ivit y owner of t he individual act ivit y. The workflows are as follows: Pr oj e ct m a na ge m e nt w or k flow . This consist s of a four- pass it erat ion planning and t racking act ivit y t o det ail and m onit or t he RUP phases and it erat ions at t he level of m easurable crit erion and personal account abilit y.

-160-

Convergent Architecture

ƒ

ƒ

ƒ

ƒ ƒ

ƒ ƒ

ƒ

ƒ ƒ

ƒ

ƒ

ƒ ƒ ƒ ƒ ƒ

Spe cia lize d t e chnologie s. Archit ect ural I DE for t racking and m onit oring. D e ve lopm e nt e nvir onm e nt w or k flow ( suppor t ing) . This set s up and verifies t he developm ent environm ent for each t eam m em ber. Act ivit y ow n e r s. Developm ent t oolsm it h. Spe cia lize d t e chnologie s. I nt im at ely fam iliar wit h t he set up and t est of t he ent ire suit e of developm ent t ools and t echnologies used in a syst em developm ent proj ect . The basic set of t ools consist s of t he archit ect ural I DE, unified configurat ion m anagem ent ( UCM) t ools, unit t est ing t ools, applicat ion server environm ent , and Web server environm ent . Configur a t ion a nd ch a nge m a na ge m e nt ( CCM ) w or k flow ( suppor t in g) . This defines and set s up t he CMM feat ures required by a part icular t eam m em ber. Act ivit y ow n e r s. Configurat ion m anager. Spe cia lize d t e chnologie s. ClearCase UCM syst em . Ana lysis- by- de sign ( ABD ) w or k flow . This consolidat es t he RUP business m odeling, t he RUP requirem ent s, and t he RUP analysis and design workflows int o t hree phases of convergent refinem ent , each represent ing a crit ical st age in t he m et am orphosis of a business st rat egy int o t he OPRs of a convergent syst em .

AM FL Y

ƒ

Act ivit y ow n e r s. Syst em proj ect m anager.

Act ivit y ow n e r s. Assem bly developer.

Spe cia lize d t e chnologie s. Archit ect ural I DE w it h focus on t he upst ream m odules C- BOM, C- RAS, and C- REF/ Rose; ClearCase UCM client s; Front - Page ( or equivalent ) ; Requisit e- Pro ( or equivalent ) . I m ple m e n t a t ion cycle w or k flow . This is t he m odel- driven refine, generat e, edit , deploy, and t est cycle.

TE

ƒ

Chapter 6: The Development Process

Act ivit y ow n e r s. Developer. Spe cia lize d t e chnologie s. Archit ect ural I DE w it h a focus on downst ream m odules C- REF/ Rose, C- GEN, and C- I X; Java I DE; J2EE applicat ion server wit h associat ed dat abase t ools; Apache server; Tom cat Web server; Cygnus GNU t ools; ClearCase UCM client s; Front Page; I nst all Anywhere; ANT- based build environm ent . Te st w or k flow . This provides explicit qualit y checks and a j ust - in- t im e diagnosis at each st age of t he developm ent life cycle. Act ivit y ow n e r s. Lead developer ( com ponent t est ing) and developers ( unit t est ing) . Spe cia lize d t e chnologie s. Archit ect ural I DE; JUnit ; inst allat ion of J2EE applicat ion server according t o t he const raint s of t he operat ional environm ent . D ocum e nt a t ion w or k flow ( suppor t ing) . This covers t he product ion of docum ent at ion, help files, and t raining m at erial. Act ivit y ow n e r s. Technical writ er.

ƒ

Spe cia lize d t e chnologie s. Fram eMaker, WebWorks, Javadoc.

-161-

Team-Fly®

Convergent Architecture

ƒ ƒ

ƒ

Chapter 6: The Development Process

D e ploym e nt a nd m onit or ing w or k flow . This provides a t ransit ion t o t he operat ional environm ent and m onit oring wit hin t he operat ional environm ent . Act ivit y ow n e r s. Assem bly developer. Spe cia lize d t e chnologie s. Operat ions- level inst allat ion of J2EE applicat ion server. [ 2]

Defining every det ail of soft ware developm ent as an act ivit y is im possible. Trying t o achieve t his would bloat t he process t o t he point where nobody paid any at t ent ion t o it . Not only w ould it be t oo volum inous, it also w ould be unrealist ically const raining. An effect ive process m ust be very select ive about what it prescribes and what it leaves up t o t he well- defined responsibilit ies of t he I T organizat ion.

Pr e pa r a t or y a nd Cr oss- Pr oj e ct W or k flow s The preparat ory and cross- proj ect workflow s exist out side of t he cont ext of individual proj ect s. These workflows begin before t he first proj ect and cont inue across proj ect generat ions. They are t he cont inuum t hat init ializes, accom panies, and cont rols t he overall const ellat ion of proj ect s. I T- Envir onm e nt W or k flow

ƒ ƒ ƒ ƒ ƒ

ƒ

ƒ

ƒ

The I T- environm ent workflow addresses t he recurring, ongoing act ivit ies of each I T organizat ion in support of t he overall I T effort . These act ivit ies are in fulfillm ent of t he organizat ion's responsibilit ies as defined in t he I T- organizat ion m odel. Act ivit y. Boot st rap t he I T organizat ion. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. I T- organizat ion m anager, chief archit ect , st eering t eam . Ar t ifa ct s pr oduce d/ r e fine d. I T- organizat ion m odel and im plem ent at ion plan. Guide line s a nd a r t ifa ct / t ool usa ge : The I T- organizat ion m anager uses t he I T- organizat ion m odel as a t em plat e and develops a concret e I T- organizat ion m odel for t he specific sit uat ion. Based on t he m odel, he or she t hen fills t he organizat ion m anager posit ions of it s direct suborganizat ions. The st eering t eam now exist s. I n conj unct ion wit h t he st eering t eam , each organizat ion owner refines t he aspect s of t he I T- organizat ion m odel relevant t o his or her organizat ion. Based on t he refined m odel, t he organizat ion m anager set s up and prepares t he organizat ion t o fulfill it s responsibilit ies. The rule of t hum b for t his act ivit y is t o st art sm all and build once t hings work, t hat is, get t hings working at a sm all scale before scaling up. Once prepared, t he archit ect ure organizat ion kicks off t he Tbar business m odeling and requirem ent s workflow ( discussed lat er) , which, t hrough t he ident ificat ion of syst em developm ent proj ect s, influences t he speed and ext ent of t he I T- environm ent workflow. Wit h t he est ablishm ent of t he st eering t eam and t he kickoff of t his first T- bar workflow, t he self- regulat ing cycle of operat ional workflows has com m enced. As st at ed in t he I T- organizat ion m odel, t he act ive, operat ional w orkflows are owned as a whole by t he I T- organizat ion m anager. This sounds like m ore work t han it really is. Since each inst ance of an act ivit y wit hin a workflow has it s own owner, t he I T- organizat ion

-162-

Convergent Architecture

Chapter 6: The Development Process

m anager is m ore a proact ive m onit oring and escalat ion point t han anyt hing else. I t sim ply confirm s t he I T- organizat ion m anager as t he t oplevel owner of t he operat ional developm ent process. This should not be confused wit h t he ow ner of workflow definit ions—t he definit ion of t he process. I t is t he chief archit ect who m aint ains t hese definit ions as part of t he Convergent Archit ect ure- st yle reference. T- Ba r Busine ss M ode ling a nd Re quir e m e n t s W or k flow This workflow and t he ABD workflow det ailed here exercise different hierarchical levels of t he T- t echnique as described in convergent engineering ( Taylor 1995) and unanim ously endorsed by Microsoft ( Am bler 1997) and RUP ( Krucht en 2000) . I n addit ion, bot h workflows and t heir respect ive t ools in t he archit ect ural I DE const it ut e a st yle- specific applicat ion of t he responsibilit y- driven design ( RDD) concept s form ulat ed by convergent engineering ( Taylor 1995) and RUP's " Work Guidelines: Role Playing" ( Rat ional 2000) . Com plem ent ing t he T- t echnique, t echniques such as class responsibilit y collaborat ion cards ( CRC) and w alk- t hrough, as described in convergent engineering and RUP, are used t o derive and validat e requirem ent s and t o ensure a high- fidelit y business m odel. The T- bar business m odeling and requirem ent s workflow ( or sim ply T- bar w orkflow) derives it s nam e from it s focus on t he highest level of business m odeling as represent ed by t he bar of t he T—t he crossbar of t he T—in t he T- t echnique. I t serves t o ident ify business requirem ent s and business part it ioning as a prerequisit e t o defining syst em developm ent proj ect s. This w orkflow init iat es syst em developm ent proj ect s and, as such, init iat es t he proj ect m anagem ent workflow. I t also serves as t he t op- level consolidat or of feedback and requirem ent s arising from t he sum of all syst em developm ent proj ect s. Effect ive global opt im izat ion of t he business and it s I T infrast ruct ure is achieved by consolidat ing t he feedback and requirem ent s at t his level, according t o t he Tt echnique. This is also where t he non- I T- relat ed organizat ional im pact of syst em developm ent proj ect s is assessed, com m unicat ed, and coordinat ed w it h t he ent ire business and it s proj ect s. ƒ ƒ ƒ ƒ ƒ ƒ ƒ

This workflow com prises t he following ordered act ivit ies: T- ba r busine ss a na lysis. This produces t he t op- level OPR business m odel, including scenarios and analyses of cont ext s, const raint s, and urgency, and it produces proj ect proposals. Pr oj e ct init ia t ion a n d t r a ck ing. This init iat es syst em developm ent proj ect s or ot her proj ect s in t he I T organizat ion. Globa l r e quir e m e nt s m a na ge m e nt . This provides uniform priorit izat ion, coordinat ion, dispat ching, and t he t racking of requirem ent s, including change request s from diverse sources and levels. Act ivit y. T- bar business analysis. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Chief archit ect , business m anagers ( sponsoring client s or t heir represent at ives) and dom ain expert s, I T- organizat ion m anager, requirem ent s m anager, lead developers. Ar t ifa ct s pr oduce d or r e fine d. Top- level business obj ect m odel, cont ext diagram s, proj ect proposals. Guide line s a nd a r t ifa ct / t ool usa ge :

-163-

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 6: The Development Process

The chief archit ect or an appropriat ely experienced convergent archit ect heads up t his act ivit y t o ensure effect ive inform at ion m odeling and requirem ent s gat hering. The archit ect defines and m ediat es T- bar business analysis sessions. Anot her archit ect or lead developer m ay assist during m odeling and result s processing. The I T- organizat ion m anager coordinat es and adm inist ers part icipat ion of t he appropriat e m ixt ure of business m anagers and dom ain expert s. The sessions norm ally last t wo t o four days; t he business m anagers and dom ain expert s are only involved half- days. There are a m axim um of t hree act ive business m anagers or dom ain expert s per session plus t he archit ect and, opt ionally, one lead developer. This const it ut es a T- bar business analysis t eam ( or T- bar t eam ) . During t he m orning, t he j oint requirem ent s gat hering and m odeling act ivit y proceed according t o t he convergent engineering schem a show n in Figure 6.2. I n t he aft ernoon, t he business m anagers and dom ain expert s are freed up t o carry out t heir daily business. During t his t im e, t he archit ect and lead developer work on consolidat ing, docum ent ing, and generally im proving t he m odel. Above all, t hey advance int o t he invent ion phase shown at t he right of t he figure. The result s of t he consolidat ed business m odel and t he t ent at ive invent ion result s are t hen t he basis for discussion when t he session resum es t oget her wit h t he business m anagers and dom ain expert s on t he next m orning.

Figur e 6 .2 : The core analysis- by- design process. Sim ple and effect ive. Business com ponent s evolve increm ent ally. The first m odel is usually a real eye- opener. Session result s t hat include t op- level OPRs and t op- level business scenario m odels are recorded in t he C- BOM t ool. The analysisby- design workflow ( discussed lat er) and t he C- BOM sect ion of Chapt er 7 provide det ails on t his t ask. I n addit ion, cont ext inform at ion and const raint s of t he I T and organizat ional environm ent are recorded in sket ches. The need for im m ediat e, ad hoc responses t o problem s in t he exist ing operat ional environm ent is also priorit ized. Figure 6.3 exhibit s t he necessary effort split along t he road t o convergent syst em s.

-164-

Convergent Architecture

ƒ

ƒ

Chapter 6: The Development Process

Figur e 6 .3 : The effort split : Graduat ing t o convergence. Convergent Arciht ect ure deals wit h t he realit y of t he exist ng I T environm ent . The session ends wit h one or m ore proposals for syst em developm ent proj ect s t oget her wit h assessm ent s of t hose proposals t hat address t he organizat ional and business im pact of t he proj ect . Requirem ent s deem ed as t angent ial, secondary, or of int erest at a lat er st age are recorded, sanit y- checked, and handed over t o t he requirem ent s m anager for furt her coordinat ion and qualificat ion in t he norm al course of t he global requirem ent s m anagem ent act ivit y. As part of t he T- bar t eam , t he I T- organizat ion m anager sanit y- checks and refines t he proj ect proposals from t he organizat ional perspect ive. The chief archit ect and lead developers ensure realist ic developm ent est im at es in t he proj ect proposal, t hus avoiding long, cost ly sanit y- check cycles. The I T- organizat ion m anager t hen produces proj ect proposals and proceeds t o t he proj ect init iat ion and t racking act ivit y. The T- bar business analysis is repeat ed regularly at t he discret ion of t he chief archit ect or t he I T- organizat ion m anager. Norm ally, t his w ill occur at least t wice a year. The very first T- bar business analysis m ay require num erous sessions t o get past t he init ial organizat ional im pedances and learning curve. Figure 6.2 illust rat es t he core analysis- by- design process from convergent engineering. This process is used at t wo different levels of granularit y in t he Convergent Archit ect ure. I t is used by t he T- bar business analysis act ivit y t o ident ify and st ruct ure t he high- level OPRs and t he associat ed const raint s and requirem ent s of t he business at large. I t is t hen used at t he analysis- by- design workflow t o successively refine t he T- bar result s int o operat ional OPRs. Figure 6.3 shows t hat m igrat ing from a t radit ional I T landscape t o a convergent syst em requires a planned effort split . An organizat ion graduat es over t im e from problem - driven responses t o archit ect ure- driven change. To ensure t hat t his graduat ion t akes place, t he im m ediat e- response t rack m ust be recognized and addressed by t he convergent syst em s t rack. No m at t er how m ot ivat ed t he I T organizat ion is, an ent ire ent erprise cannot be m igrat ed overnight . I nst ead, t he convergent archit ect ensures t hat new barriers t o convergence do not occur as a

-165-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ ƒ

ƒ

ƒ

Chapter 6: The Development Process

result of im m ediat e- response effort s. As t he capabilit ies of t he I T organizat ion and syst em s in t he convergent syst em s t rack increase, t he dem ands on t he im m ediat e- response t rack are reduced t hrough t he m anaged m igrat ion of exist ing I T syst em s or by t he int roduct ion of new proj ect and syst em design t echniques. The speed of progression int o t he convergent syst em s t rack is organizat iondependent . An organizat ion t hat is pushed t oo fast m ay go int o a m ode of dest ruct ive resist ance t o change. One of t he prim ary reasons for regular T- bar business analysis act ivit y is t o const ant ly t ake t he pulse of t he organizat ion and t o adj ust t he correct speed and st ride of change at t he proper level before expensive set backs occur during proj ect s. Act ivit y. Proj ect init iat ion and t racking. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. I T- organizat ion m anager, proj ect m anager/ syst em proj ect m anager, st eering t eam , sponsoring client , requirem ent s m anager, lead developers. Ar t ifa ct s pr oduce d or r e fine d. Consolidat ed proj ect reviews. Ot he r e nd r e sult s. Proj ect kickoff or t erm inat ion. Guide line s a nd a r t ifa ct / t ool usa ge : The proj ect proposals from t he T- bar business analysis act ivit y are used by t he I T- organizat ion m anager t o init iat e new proj ect s. This is a separat e act ivit y because t he init iat ion of a proj ect norm ally requires considerable effort , part icularly in large organizat ions. Whet her all proposed proj ect s act ually progress beyond t he incept ion phase is det erm ined during t his act ivit y. The I T- organizat ion m anager, as a m em ber of t he T- bar t eam , underst ands and can com m unicat e t he int errelat ionship bet ween t he proj ect proposals and aspect s of t he business st rat egy. I f a proj ect does not progress beyond t he incept ion phase, t hen adj ust m ent s in all relat ed proj ect s as well as consequent ial effect s on t he business st rat egy are im m ediat ely m ade at t he T- bar business analysis level. Maj or deviat ions from proj ect proposals m ay call for an except ional T- bar business analysis session. Such except ional sessions are, on t he one hand, a sign of healt hy it erat ive analysis by design and, on t he ot her hand, should send a warning signal t hat t he Tbar business analysis is not as effect ive as it should be. The t ight loop bet ween t he proj ect init iat ion and t racking and T- bar act ivit ies ensures t hat t im ely correct ions and opt im izat ions are m ade. I n t his act ivit y, t he I T- organizat ion m anager sim ply init iat es t he proj ect m anagem ent workflow ( discussed lat er) . As described in t he workflow, proj ect init iat ion requires t he allocat ion of a pot ent ial proj ect m anager and t he clear int ent by a sponsoring client t o fund t he proj ect based on t he init ial est im at es in t he proj ect proposal. The proj ect init iat ion act ivit y proceeds in t his scope unt il t he proj ect is officially kicked off or t erm inat ed by t he st eering t eam . The proj ect m anager drives t he init iat ive t o achieve kickoff. However, proj ect kickoff and reviews are norm al responsibilit ies of t he I T- organizat ion st eering t eam s, and t hey occur in t he course of t he regular st eering t eam m eet ings as run by t he I Torganizat ion m anager. Successfully init iat ed proj ect s are t racked at t he st eeringt eam level t o ensure global opt im izat ion across all proj ect s t hrough t im ely input t o ongoing T- bar act ivit ies as well as feedback t o prevent a drift from T- bar goals. The procedure for t racking is sim ple: The organizat ion m anager of t he syst em developm ent organizat ion present s t he st at us of each act ive proj ect , whereas t he ot her organizat ion m anagers, which include t he chief archit ect ( and all norm al m em bers of t he st eering t eam ) ,

-166-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ

ƒ

Chapter 6: The Development Process

provide input and feedback regarding problem s and pot ent ial opt im izat ion or synergies. Act ivit y. Global requirem ent s m anagem ent . Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Requirem ent s m anager, chief archit ect , I T- organizat ion m anager, st eering t eam . Ar t ifa ct s pr oduce d or r e fine d. Requirem ent s pool. Guide line s a nd a r t ifa ct / t ool usa ge : Requirem ent s t racking includes change m anagem ent in t he Convergent Archit ect ure. I t is a st raight forw ard act ivit y if t aken seriously. However, it cannot be handled in an ad hoc m anner. The key t o success is having a dedicat ed and well- organized requirem ent s m anager working at t he nonpart isan level of t he archit ect ure organizat ion, as shown in t he I Torganizat ion m odel. The requirem ent s m anager organizes all requirem ent s in a global requirem ent s pool. The pool m ay be a sim ple docum ent , but larger I T organizat ions require a m ore sophist icat ed t ool such as Rat ional Requisit ePro. At a m inim um , t he global requirem ent s pool m ust order requirem ent s according t o t he source, priorit y, responsible sink, and st at us. Once a priorit y is set , t he requirem ent s m anager officially dispat ches t he requirem ent t o a sink ( defined lat er) and t racks t he st at us of t he requirem ent . There is no clear definit ion of what a requirem ent m ust look like or how it will be fulfilled. This is because requirem ent is a very am biguous w ord. Nevert heless, a w hole lot of t hese am biguous requirem ent s appear from all direct ions at all t im es in an I T organizat ion. I f t hese are sort ed and handled wit h a due port ion of discipline according t o t he following sim ple procedure, a whole lot of progress will be m ade. Get t ing m ore specific, t he requirem ent s m anager willingly accept s any sort of requirem ent , no m at t er how obscure, t hat has not found an official sink anywhere else in t he I T organizat ion. I t is easy t o locat e an official sink for m any requirem ent s by locat ing t he appropriat e responsibilit y in t he I T organizat ion. However, j ust locat ing t he responsible person is not all; t he person m ust be able t o accept and fulfill t he requirem ent . Thus, an official sink is anybody w illing t o t ake on official responsibilit y for fulfilling a requirem ent . This m eans t hat t he source and sink agree on t he definit ion and priorit y of t he requirem ent . Taking official responsibilit y m eans com m it t ing t o fulfill t he requirem ent along t he lines of t he official organizat ional and workflow st ream of t he I T organizat ion. This includes all side effect s ( t im e, resources, risk, im pact s) associat ed wit h fulfilling t he requirem ent . I f any doubt exist s about t he official sink, t hen t he requirem ent is subm it t ed t o ( t hrough) t he requirem ent s m anager. Such sinkless requirem ent s can range from arbit rary good ideas t o highpriorit y change request s from t he operat ional syst em s organizat ion t hat cannot be allocat ed direct ly t o a part icular assem bly owner. Anot her exam ple would be if t he assem bly owner and t he source of t he change request cannot agree im m ediat ely on t he solut ion, priorit y, or fulfillm ent t im ing of t he requirem ent . I n t his case, no official sink has been found, and it is im m ediat ely escalat ed t o t he requirem ent s m anager. Thus, everybody knows where t o go wit h every requirem ent , no m at t er how obscure t he requirem ent m ay be. There is no im pedance t o t he flow of requirem ent s, and all requirem ent s find a responsible owner according t o t he pat h of least resist ance. Requirem ent s t hat fit int o t he norm al work st ream are handled properly wit hout any ext ra adm inist rat ive overhead. The rem aining requirem ent s are handled by t he requirem ent s m anager as follows:

-167-

Convergent Architecture

ƒ

Chapter 6: The Development Process

Once a requirem ent lands wit h t he requirem ent s m anager, it is t racked in t he requirem ent s pool. Thus, all requirem ent s in t he I T organizat ion end up eit her in t he official plan of a workflow act ivit y or an I T organizat ion or in t he requirem ent s pool, or bot h. Once in t he requirem ent s pool, t he requirem ent s m anager goes about finding an official sink for t he requirem ent . To find t he official sink, t he requirem ent s m anager sort s, filt ers, and consolidat es t he requirem ent wit h t he exist ing requirem ent s pool. Based on his or her invest igat ions and consolidat ion, t he requirem ent m ay be dispersed int o part s of ot her exist ing requirem ent s. The requirem ent s m anager t hen set s out t o achieve a consensus regarding priorit ies via t he official responsibilit y hierarchy of t he I T organizat ion. Based on t his consensus, he or she t hen dispat ches t he requirem ent s int o official sinks such as t he owners of current proj ect proposals, owners of assem blies, or organizat ion m anagers. Anot her com plet ely viable official sink is t o declare t he requirem ent as insignificant . Declaring a requirem ent as insignificant can only be done by t he requirem ent s m anager as a nonpart isan represent at ive of t he ent ire I T organizat ion. Requirem ent s t hat cannot be resolved reasonably t o an official sink are escalat ed by t he requirem ent s m anager t o t he I Torganizat ion m anager, who m ay bring t he issue t o t he st eering t eam for resolut ion. The st eering t eam is t hen in t he posit ion t o im m ediat ely address any side effect s due t o an except ional resolut ion t hat m ay be inconsist ent wit h t he current ly act ive workflow. Ar chit e ct ur a l Evolut ion W or k flow

ƒ ƒ ƒ ƒ ƒ

An inst ance of t he Convergent Archit ect ure defines t he w ay t he ent ire I T organizat ion operat es, including how it designs and delivers convergent syst em s. Clearly, t his is a long- t erm approach t hat m ust t ake changes and t he passage of t im e int o account t o be successful. The archit ect ural st yle workflow m akes sure t hat changes relevant t o t he archit ect ural st yle t ake place in a proact ive, const ruct ive m anner as part of t he norm al, self- opt im izing act ivit ies in t he I T organizat ion. Through t his w orkflow, t he archit ect ural st yle em braces change as part of it s own design and ensures t hat it does not begin t o im pede it s own goals wit h t he passage of t im e. This act ivit y st art s wit h t he creat ion of t he very first inst ance of t he Convergent Archit ect ure. Act ivit y. Archit ect ural evolut ion. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Chief archit ect , st eering t eam . Ar t ifa ct s pr oduce d or r e fine d. Convergent Archit ect ure st yle reference. Guide line s a nd a r t ifa ct / t ool usa ge : As out lined in Chapt er 5, t he Convergent Archit ect ure st yle reference describes an organizat ion- specific inst ance of t he Convergent Archit ect ure as defined in t his book. The inst ance m ay be a one- t o- one applicat ion of t he ent ire st yle book or a docum ent ed variant t hat rem ains com pat ible wit h t he archit ect ural and developm ent m odels, bot h described in t his book. The chief archit ect allocat es adequat e t im e t o m aint ain t he Convergent Archit ect ure st yle reference and t o ensure t hat changes are underst ood and im plem ent ed t hroughout t he I T organizat ion. The ext ent of t his effort will depend on how far t he variant inst ance of t he Convergent Archit ect ure deviat es from m ainst ream evolut ion of t he archit ect ural st yle. Alt hough one of t he principal goals of t he st yle is t o reduce t he invasive

-168-

Convergent Architecture

ƒ

Chapter 6: The Development Process

effect s due t o change, change will occur. For exam ple, even a st able, fundam ent al st andard such as UML will evolve. Many, if not m ost , changes t o t he archit ect ural st yle will have a m inor im pact so long as t hey are int roduced increm ent ally. The t rick is t o handle t his st eadily and st ep by st ep. The best st rat egy an organizat ion can t ake t o avoid problem s due t o change while at t he sam e t im e benefit ing from new developm ent s is t his ongoing act ivit y of observat ion and increm ent al change—t hat is, evolut ion. This allocat ion of t he chief archit ect 's t im e is a wise invest m ent in const ruct ive foresight t o ensure t hat changes t ake place at t he best t im e and at t he right place. I n addit ion t o cont inuous invest m ent s by t he chief archit ect , t his act ivit y will involve effort s from ot her m em bers of t he I T organizat ion. For exam ple, t he archit ect ural I DE m ay need t o be adapt ed by t he t oolsm it hs w ho are responsible for it s usage in individual proj ect s. However, t im ely adapt at ions t o t he reference I DE will help avoid cost ly problem s in act ive proj ect s down t he road.

Pr oj e ct M a n a ge m e n t W or k flow The proj ect m anagem ent workflow applies t he RUP phases, it s m ilest ones, and it s concept s on increm ent al developm ent . This begins wit h a canonical it erat ion planning and t racking act ivit y t hat applies an opt im izing four- pass approach. This planning act ivit y is canonical in t he sense already used in t he I T- organizat ional m odel. I t is applied equally t o every it erat ion wit h slight variat ions relat ive t o t he current life- cycle phase of a proj ect . This canonical planning act ivit y in conj unct ion wit h concept ual proxim it y of t he I T organizat ion and t he archit ect ural I DE enables a sim ple, highly effect ive proj ect m anagem ent workflow. The proj ect m anagem ent workflow coordinat es and drives all ot her canonical proj ect workflows. I t also int eract s wit h t he cross- proj ect workflows, in part icular wit h t he T- bar business analysis act ivit y as described previously. This int eract ion is int ent ional along t he lines of t he T- t echnique: The proj ect m anagem ent workflow handles t he lower levels of t he T, as denot ed by t he vert ical st rut of t he T, whereas t he T- bar business analysis act ivit y absorbs and consolidat es inform at ion at t he upper level of t he T, t he T- bar. This relat ionship is illust rat ed in Figure 6.4.

Figur e 6 .4 : The flow and scope of an it erat ion. The figure also illust rat es t he logical orient at ion of t he ot her canonical proj ect workflows, from t op t o bot t om , along t he crit ical pat h of each it erat ion in a syst em developm ent proj ect . The proj ect m anagem ent workflow init iat es and t erm inat es each it erat ion, as indicat ed by t he innerm ost arrow in t he figure ret urning from t he

-169-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

ƒ

ƒ

Chapter 6: The Development Process

review and t erm inat ion of an it erat ion at t he bot t om , back t o t he t op of t he workflow, where t he next it erat ion is planned. Clearly, t he proj ect m anagem ent workflow bracket s t he ot her crit ical- pat h workflows int o t he cont ext of planned it erat ions of a proj ect . As em phasized in t he RUP, t he workload dist ribut ion am ong t he workflows is highly dependent on t he current phase ( and st at e) of t he proj ect . The int ended dist ribut ion of workload across t he it erat ions of a proj ect is signified by t he scales t o t he right of t he figure. Last ly, t he vert ical posit ioning of t wo support ing workflows, t he developm ent environm ent workflow and t he configurat ion and change m anagem ent ( CCM) workflow, indicat e t hat , alt hough im port ant , t hey do not lie direct ly in t he crit ical pat h of each it erat ion. These support ing workflows are ongoing in t he cont ext of a proj ect wit h a peak load for workers from t he I T support organizat ion t ow ard t he beginning of t he proj ect . Act ivit y. Canonical it erat ion planning and t racking ( base act ivit y) , wit h phase- specific variant s each covered individually lat er aft er t he guidelines covering t he canonical aspect s: I ncept ion- phase variant ( proj ect init iat ion) Elaborat ion- phase variant Const ruct ion- phase variant Transit ion- phase variant Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Syst em proj ect m anager, assem bly developer, ot her lead developers in t he syst em developm ent proj ect , convergent archit ect . Ar t ifa ct s pr oduce d or r e fine d. Syst em proj ect plan ( long- t erm developm ent st rat egy, current it erat ion plan wit h work orders for bot h assem bly and com ponent developm ent proj ect s) . Guide line s a nd a r t ifa ct / t ool usa ge : Each it erat ion of a syst em developm ent proj ect begins wit h a variant of t he com m on canonical it eration planning and t racking act ivit y described here. The canonical procedure com bines t he fact ors required for t im ely, realit y- driven opt im izat ion of each proj ect it erat ion. Realit y- driven m eans t hat t he part icipant s in t he proj ect are consist ent ly freed from t heir respect ive illusions ( opt im ism , wishful t hinking, overest im at ion of capabilit ies, qualit y of requirem ent s) t o arrive at a plan based on a consensus of t he real const raint s and requirem ent s in t he proj ect . To achieve t his, each it erat ion is planned using a rapid, four- pass process. This process produces, or updat es, t he long- t erm developm ent st rat egy docum ent and t he current it erat ion plan. The current it erat ion plan exist s in t he form of a feat ures sum m ary and a sim ple t ask ownership m at rix ( TOMA) , which is covered in m ore det ail wit h Figure 6.6. Each t ask in t he TOMA com prises a work order specifying t he five W's ( who, what is done, when, wit h whom , and where do t he deliverables go) , as described lat er, for each specific t ask. This short fourpass session and it s result ing TOMA are all t hat are needed t o guarant ee t hat each part icipant cont ribut es t he m axim um t o t he progress, synergy, risk m anagem ent , t racking, and st eering of a proj ect in harm ony wit h ot her act ive proj ect s. I n addit ion, t his approach leads t o a significant reduct ion of t he num ber of it erat ions required for a given set of feat ures. This is so because t he sanit y- checking capacit y of t he it erat ive approach is am plified by t he four- pass approach t o planning. The following subsect ions explain how t his works. The init ial planning for each and every it erat ion proceeds according t o t his logic: The syst em proj ect m anager schedules a four- pass it erat ion planning session wit h t he assem bly developer and t he ot her lead

-170-

Convergent Architecture

Chapter 6: The Development Process

TE

AM FL Y

developers slat ed for t he syst em developm ent proj ect . How t he init ial group of lead developers is defined is explained in t he sect ion on t he incept ion- phase variant . The requirem ent s m anager also part icipat es at t he beginning and end of t he session. I n addit ion, t he sponsoring client and dom ain expert s should be on call in order t o im m ediat ely clear up issues. The session can last anywhere from t wo hours t o four days, depending on t he ext ent of t he proj ect and, above all, on t he num ber of illusions t hat st ill exist in t he group's collect ive m ind. The session t akes place in a room equipped wit h plent y of whit e- board space and t he capabilit y t o copy t he cont ent s of t he whit e boards ( copy boards) . The four- pass it erat ion planning session t hen proceeds according t o t he flowchart illust rat ed in Figure 6.5.

Figur e 6 .5 : Planning an it erat ion: The four- pass approach. Carry out t hese st eps wit h t he lead developers and prim ary cust om er. ƒ

The four- pass approach is as follows: Pa ss 1 ( t a lk - t hr ough) . I n pass 1, t he assem bly developer groups and list s t he requirem ent s t o be fulfilled as blocks on t he whit e boards. The requirem ent s are grouped int o m aj or requirem ent s and relat ed subrequirem ent s. The assem bly developer norm ally has a good idea of t he requirem ent s on t he it erat ion. The source of t hese requirem ent s is t he review of t he previous it erat ion ( if available) , t he proj ect proposal, and any new input from t he requirem ent s m anager. Then all requirem ent s are broken down in t erm s of deliverable feat ures, core business feat ures, t echnical feat ures, and proj ect - specific I T- organizat ional aspect s. The core business feat ures are list ed in t erm s of business m odels or convergent com ponent s. Feat ures are broken down int o subfeat ures if necessary t o enable t he realist ic est im at ion of resource requirem ent s: worker skills, t im e, and infrast ruct ure. While list ing t he

-171-

Team-Fly®

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 6: The Development Process

blocks of requirem ent s/ feat ures, t hey are also priorit ized: 1 being highest priorit y and 3 t he lowest . Things t hat m ust be accom plished t oget her or as prerequisit es for ot hers are recognized in t he priorit ies. Also, t he dependencies from ot her proj ect s ( ot her assem blies) t hat depend on t he assem bly being planned m ust be reflect ed in t he priorit ies—a clear responsibilit y of t he assem bly developer. The part icipant s set t he priorit ies as a group by reaching a consensus or t hrough a consensus via dem ocrat ic m aj orit y if reaching a com plet e consensus proves difficult . This st ep ensures t hat priorit ies, sequencing, and prerequisit es are agreed on am ong part icipant s, bot h proj ect m anagem ent and developers, from t he st art . Pa ss 2 ( a lloca t e a nd e st im a t e ) . I n pass 2, realist ic resource est im at es ( worker, worker t im e, infrast ruct ure) are m ade for all priorit y 1 feat ures and requirem ent s. Once a worker has been assigned, t he fulfillm ent of t he feat ure or requirem ent becom es a t ask for t he worker. The resource est im at e is for everyt hing relat ed t o t he t ask up t o t he delivery of t he result s at t he end of t he it erat ion. Thus, t he est im at e also includes t est ing and adm inist rat ive effort s, for exam ple. All part icipant s in t he session m ust agree on t he resource est im at e t o ensure t hat t he feat ure is defined adequat ely. I f t hey cannot agree, t hen t he feat ures and requirem ent s in quest ion m ust be broken down int o furt her det ail. I f t his is not possible, an addit ional requirem ent for furt her invest igat ion usually is t he solut ion. At best , a person is im m ediat ely allocat ed t o carry out t he t ask inst ead of defining a worker role. This nails down t he precise skill set and perm it s opt im al developer synergies t o be creat ed by t he experienced t eam of lead developers. Allocat ing t he proper persons t o requirem ent s significant ly influences t he effort est im at es bot h for t he t ask it self and in ot her areas of t he developm ent effort . Thus, t he im m ediat e allocat ion of a person m akes t he est im at e m ore precise. I f no person can be allocat ed direct ly, t hen t he det ails regarding required skills and experience m ust be recorded for t he next pass. Pa ss 3 ( w a lk - t hr ough) . This pass is t he first sanit y- check and adj ust m ent pass. The resource est im at es from pass 2 are list ed and com pared wit h t he available resources for t he proj ect . At t his point , hard decisions are m ade by t he planning t eam or, in case a problem cannot be resolved, m ust be escalat ed by t he t eam . Three so- called free variables can be adj ust ed in t his pass: feat ure set ( requirem ent s) , t im e invest ed, and available w orker skills. These are t he only t hree variables t hat need t o be considered. They are known as free variables t o suggest t heir sim ilarit y t o free variables in classic engineering and physical science disciplines. Each free variable m ay be adj ust ed and t hen t he t ot als recalculat ed. Tim e and person skills can be convert ed t o cost , of course, at any t im e. I n cont rast t o som e science disciplines, t he t hree free variables not ed here are not com plet ely independent of one anot her. This is one reason why t he experience of t he lead developers is im perat ive in t he planning effort . For exam ple, dependencies bet ween t he feat ures m ust be addressed wit h each change of t he free variables. Also, t he t ot al t im e allocat ed for an it erat ion should not be st ret ched, cont rary t o t he RUP's recom m ended pract ice for it erat ions. As a rule of t hum b, t he m ean it erat ion lengt h should not be m ore t han 12 weeks. Pa ss 4 ( r un- t hr ough) . I n t he final pass, t he t eam runs t hrough t he result s of pass 3, checks for consist ency and consensus, finalizes t he so- called W5 det ails ( discussed lat er) for each t ask, and records t he unfulfilled requirem ent s/ feat ures. The W5 det ails ensure t hat all feat ures are planned at t he level required by t he syst em proj ect m anager t o const ruct t he TOMA and it s associat ed work plans. Figure 6.6 illust rat es a TOMA. The colum ns in t he

-172-

Convergent Architecture

Chapter 6: The Development Process

TOMA represent t he nam ed t asks t o be com plet ed during t he it erat ion. The rows in t he TOMA represent t he workers ( persons) available t o t he proj ect . I n t he TOMA, each t ask has an owner, which is denot ed by a large circle at a node in t he TOMA, as shown in t he figure. Also, t asks m ay have significant part icipant s, denot ed by t he sm aller squares in t he figure. Each t ask- owner pair in t he m at rix ( t he large circles in t he figure) is associat ed wit h it s respect ive W5 work plan det ails. The W5 specifies who ( t he owner and part icipant s) , w hat is done ( what are t he deliverables) , when ( when are t hings due) , wit h whom ( t he significant cont ribut ors) , and where t he deliverables go ( where are t he result ing art ifact s t o be delivered) . Based on t he run- t hrough consensus, t he syst em proj ect m anager t hen produces t he final feat ure list , TOMA, and W5 work plans. I n addit ion, t he syst em proj ect m anager is t he owner of a t ask for regular it erat ion reviews and t he final it erat ion review. These cum ulat ive result s com prise t he new current it erat ion plan.

Figur e 6 .6 : Work plan: The t ask ownership m at rix ( TOMA) is used t o com m unicat e w ork plans. Based on t he inform at ion qualit y won during t he it erat ion planning session, t he planning t eam produces or refines long- term prognoses for t he proj ect . This longt erm plan includes est im at es covering t he num ber and ext ent of proj ect ed it erat ions, st aged releases, t est versions, and RUP life- cycle m ilest ones. I t also form ulat es t he st rat egy for achieving t hese goals. This inform at ion is com piled by t he syst em proj ect m anager t o produce or updat e t he long- t erm soft ware developm ent plan. This plan enables t he I T organizat ion and it s st eering t eam t o m ake long- t erm forecast s and proact ive m anagem ent decisions. Updat ing t he long- t erm plan wit h each it erat ion plan ensures t he m axim um accuracy of forecast s. I t also enables t he t eam t o gain experience regarding t he qualit y of it s est im at es and t o m ore obj ect ively assess t he st at e of t he developm ent process and t he I T organizat ion. Let 's now look at proj ect phase variat ions t o t he canonical it erat ion planning and t racking act ivit y. RUP I nce pt ion- Pha se Va r ia nt ( Pr oj e ct I nit ia t ion) The proj ect init iat ion act ivit y begins wit h t he result s from t he T- bar business analysis. I t s prim ary goal is t o delim it t he proj ect dom ain and define t he solut ion st rat egy. I t begins wit h a very sm all t eam consist ing of an experienced assem bly developer, t he syst em proj ect m anager, and a few ( not m ore) ot her developers, depending on t he ext ent of t he proposed proj ect . This init iat ion t eam also m ust

-173-

Convergent Architecture

Chapter 6: The Development Process

have access t o t he relevant dom ain expert s and expert s fam iliar wit h t he exist ing operat ional I T environm ent . I n addit ion, t he convergent archit ect part icipat es in t he init iat ion t eam by providing const ruct ive feedback regarding t he developm ent st rat egy on a regular basis. The init iat ion t eam works for a period of approxim at ely one t o eight weeks t o produce t he long- t erm developm ent st rat egy. The lengt h of t his init iat ion act ivit y is essent ially dependent on t he num ber of T- prot ot ypes ( invest igat ive prot ot ypes in t he spirit of t he T- t echnique) t hat m ust be developed. There are oft en m any unknowns at t his st age because we are at t he very beginning of t he proj ect invest igat ion. However, t he proj ect proposal oft en cont ains reasonable est im at es. The precise num ber and lengt h of T- prot ot ypes and ot her t asks in t his it erat ion are det erm ined in t he it erat ion planning and t racking act ivit y, which t he init iat ion t eam also uses t o plan t his init ial it erat ion. I n t his phase, t he init iat ion t eam proceeds wit h a st ream lined approach t o t he ABD workflow ( discussed lat er) . The st ream lined approach focuses on t he crit ical unknowns and risk fact ors in t he proj ect . The scope and cont ent of t he st ream lined ABD w orkflow are at t he discret ion of t he experienced accessor developer, wit h feedback from t he convergent archit ect . The t eam produces a long- t erm developm ent st rat egy t hat consist s of crit ical result s from t he init ial ABD workflow as well as an init ial cut of t he assem bly archit ect ure reference. I t also includes t he priorit ies, cont ent , and coverage of t he proj ect ed it erat ions, wit h m ore det ail for t he early it erat ions of t he proj ect . These init ial result s m ay change significant ly during t he elaborat ion phase. Overall, t hese result s fulfill t he requirem ent s for t he RUP life- cycle obj ect ive ( LCO) m ilest one.

ƒ ƒ ƒ

At t he end of t he phase, an LCO review is carried out wit h t he init iat ion t eam , t he st eering t eam , and t he sponsoring client . The result s of t his review det erm ine whet her The proj ect should be cont inued according t o t he long- t erm developm ent st rat egy, in w hich case t he it erat ion planning and t racking act ivit y for t he first it erat ion of t he elaborat ion phase is com m enced. The proj ect proposal should be revised and a second it erat ion carried out in t he incept ion phase. The knowledge gained during t he incept ion phase requires a com plet e review at t he T- bar business analysis level, in which case t he requirem ent s and feedback are form ulat ed for input int o t he T- bar analysis act ivit y, and t he cycle begins again at t he T- bar level. RUP Ela bor a t ion- Pha se Va r ia nt The elaborat ion phase begins wit h t he first full- scale version of t he it erat ion planning and t racking act ivit y. I t s focus is on t he ABD workflow, as defined lat er. During t he it erat ions of t he elaborat ion phase, t he syst em proj ect m anager and convergent archit ect ensure well- direct ed progress of elaborat ion. The syst em proj ect m anager checks t hat t he agreed- on cont ent and schedule in t he work plans are being fulfilled. This is done in part by using t he archit ect ural I DE t o t rack t he progress of com ponent m et am orphosis in each view of t he m odel. Each view can be checked for com plet eness and int egrit y w it h it s respect ive m odel verifier in t he archit ect ural I DE. The convergent archit ect also m onit ors t he views from t he perspect ive of t he overall, cross- proj ect , cross- syst em int egrit y of t he archit ect ural st yle.

-174-

Convergent Architecture

Chapter 6: The Development Process

As elaborat ion progresses, t he assem bly developer ensures t hat each m em ber of t he assem bly developm ent t eam and it s subordinat e com ponent developm ent t eam s produce increasingly elaborat ed versions of t heir owned resources, wit h focus on t he ABD w orkflow aspect s. Rem em ber, t he ow ned resources and t he worker responsibilit ies are also defined in t he I T- organizat ion m odel. Once well elaborat ed, t he result s of t he ABD w orkflow, t he owned resources, fulfill t he requirem ent s for t he RUP life- cycle obj ect ive ( LCO) m ilest one. This m eans t hat t he assem bly developer has arrived at a st able version of t he assem bly com ponent ( also defined in t he I T organizat ion) from t he design and archit ect ural perspect ive. At t his point , significant st ruct ural changes have slowed t o t he level where UCM coverage becom es reasonable and necessary for m any art ifact s, as described in t he CCM workflow ( discussed lat er) . The rem aining effort now concent rat es on t he com plet ion, t uning, and t est ing of t he business logic. I nit ial operat ional capabilit ies norm ally should be dem onst rable at t he end of t he second it erat ion in t he elaborat ion phase. Beginning wit h t he second it erat ion, an operat ional increm ent of t he syst em is present ed in t he operat ional t est environm ent ( in t he t est cent er organizat ion) . Each of t hese operat ional increm ent s increases t he operat ional scope of t he syst em . How ever, t hey are not yet t ransit ioned int o t he operat ional syst em s organizat ion for end- user use. They rem ain in t he operat ional t est environm ent . This is so because radical changes m ay st ill occur in t he design and realizat ion of t hese increm ent s unt il lat er in t he const ruct ion phase. RUP Con st r uct ion - Ph a se V a r ia n t The const ruct ion phase const it ut es a sm oot h, pract ically unnot iceable shift of focus t oward t he im plem ent at ion cycle workflow. I n t hese it erat ions, t he ABD workflow has dim inished significant ly, wit h a proport ionat e increase of t im e spent in t he im plem ent at ion cycle and t est workflows. These workflows are now t he cent er of act ivit y, wit h t he m odels from t he ABD w orkflow st ill driving developm ent and, in part icular, code generat ion. I n our m odel- driven approach, t he ABD workflow does not com e t o an abrupt end. I t j ust shift s focus during t he it erat ion of t he const ruct ion phase, leading t o rapid increases in t he visible capabilit ies of t he syst em . The assem bly developer, deploym ent m anager, and syst em proj ect m anager plan and drive t he const ruct ion- phase it erat ions t o fulfill t he requirem ent s for deploym ent int o t he operat ional syst em s organizat ion. The last it erat ion in t his phase concludes wit h t he RUP init ial operat ional capabilit y ( I OC) m ilest one, where t he t est cent er m anager and deploym ent m anager agree t o release t he assem bly t o t he t ransit ion organizat ion for prerelease t est ing by end users in t he operat ional syst em s environm ent . RUP Tr a nsit ion- Pha se V a r ia nt The goal of t he t ransit ion phase is t he public release of t he assem bly int o general usage. I n t his phase, t he assem bly developm ent t eam works closely wit h t he t ransit ion organizat ion and focuses on t he deploym ent and m onit oring workflow. During an it erat ion, problem report s from t he deploym ent and m onit oring workflow propagat e via t he deploym ent m anager back int o t he im plem ent at ion cycle workflow aspect s of developm ent and result in new prerelease versions of t he assem bly. New feat ure requirem ent s and m aj or change request s flow t o t he

-175-

Convergent Architecture

Chapter 6: The Development Process

requirem ent s m anager, not t o t he assem bly developm ent t eam , as defined in t he requirem ent s m anagem ent act ivit y previously. I n addit ion t o t est ing t he deployed syst em , t he operat ional user support organizat ion and infrast ruct ure and base syst em s organizat ion ( see t he I Torganizat ion m odel) are brought up t o speed by t he assem bly developm ent t eam . The end of t his phase is m arked by t he t ransit ion m anager declaring t hat t he assem bly is ready for public release. This also ends developm ent for a single, versioned release of t he assem bly, which m ay be followed by subsequent versions during it s ent ire life cycle. A final review is held wit h t he assem bly developm ent t eam . This review provides const ruct ive feedback t o each of t he I T organizat ions. I n addit ion, t he review addresses furt her releases and furt her ownership of t he assem bly. I f t he norm al planning flow has not already foreseen a subsequent release, t hen t he responsibilit y for furt her planning regarding t he assem bly lies wit h t he I T- organizat ion m anager, as described in t he I T- organizat ion m odel. Alt ernat ively, t he ongoing T- bar business analysis and requirem ent s workflow m ay reinit iat e a proj ect proposal for a new version of t he assem bly at any t im e in t he due course of it s act ivit ies. Ownership of t he assem bly and it s cont ained convergent com ponent s rem ains wit h t heir respect ive developers. I f t his is not possible, t hen resource ownership for t he art ifact s revert s t o t he archit ect ure organizat ion unt il new resource owners can be assigned. Precisely t he sam e approach applies t o proj ect s developing soft ware t o be sold t o ext ernal cust om ers. The only difference, as already not ed in t he I T- organizat ion m odel, is t hat t he operat ional syst em s organizat ion m anages prerelease t est s ( bet a t est ing) wit h ext ernal cust om ers ( as sponsoring client s) during t he t ransit ion phase and, in parallel, channels t he rollout of t he soft ware product t o t he respect ive m arket ing, sales, and dist ribut ion organizat ions.

D e ve lopm e n t En vir on m e n t W or k flow

ƒ ƒ ƒ ƒ ƒ ƒ

ƒ o

The developm ent environm ent workflow is a support ing workflow t hat set s up and verifies t he t echnical environm ent for any t eam m em ber. I t also t unes t he developm ent environm ent for each new it erat ion of a proj ect as t he det ailed requirem ent s on t he developm ent environm ent change. This workflow is concerned prim arily wit h verifying t hat t he t echnical developm ent environm ent is at it s effect ive best t hroughout t he developm ent life cycle. This enables developers t o concent rat e on t heir core developm ent dut ies along t he crit ical developm ent pat h. Act ivit y. Set up and t une t he developm ent environm ent . Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Developm ent t oolsm it h, developer, or t he ot her workers requiring a developm ent - like environm ent . Ar t ifa ct s pr oduce d or r e fine d. None. Ot he r e nd r e sult s. Tuned developm ent environm ent . Guide line s a nd a r t ifa ct / t ool usa ge : The developm ent t oolsm it h and developer work closely t oget her in t his act ivit y. By assist ing t he t oolsm it h in t his act ivit y, t he developer is learning and influencing t he environm ent he or she w ill use. The first t hing t he developm ent t oolsm it h does is t o engage t he infrast ruct ure and base syst em s organizat ion t o ensure t hat t he basic hardware and soft ware plat form is operat ional. Then t he t oolsm it h and developer proceed t o j oint ly t ackle t he following t asks, m ore or less in t his order: Set up t he developer's part icular view of t he proj ect direct ory st ruct ure and ensure t hat t he backup st rat egy is in order.

-176-

Convergent Architecture

o

o

o

Chapter 6: The Development Process

Creat e t he physical UCM st ruct ure in t he local environm ent and t he views appropriat e for t he current phase of developm ent . The det ail and range of t he views usually change as t he proj ect progresses. The art ifact s t hat need t o be m anaged in each phase of t he proj ect are covered in t he CCM workflow ( see Figure 6.7) .

Figur e 6 .7 : Workflow, t ools, and core art ifact s. Set up t he local archit ect ural I DE and local runt im e/ t est environm ent ( see Chapt er 7 and t he following t est workflow sect ion) . This includes t he applicat ion server and it s st orage t ier ( for exam ple, t he underlying dat abase) . Configure t hese t o use t he CCM and backup st rat egy as appropriat e for t he current phase of t he proj ect ( see t he CCM workflow sect ion) . The t echnical CCM capabilit ies are set up and verified t oget her wit h t he reposit ory t oolsm it h. Test t he developm ent environm ent from beginning t o end t o reduce t he possibilit y t hat problem s will be discovered lat er w hen t hey m ay inconvenience t he ent ire developm ent t eam . Using t he reference t echnologies described in t his book, it is possible t o carry out t hese t est s com plet ely aut om at ically. This precedes using ANT procedures ( ANT 2000) t o call and exercise each t ool used along t he crit ical developm ent pat h. An aut om at ed t est procedure at t his st age provides all t he advant ages it has anywhere else: predict able result s, fast and sim ple, enabling increm ent al

-177-

Convergent Architecture

ƒ

Chapter 6: The Development Process

im provem ent s. See t he Convergent Archit ect ure Web sit e for m ore inform at ion and resources regarding such t est procedures. Set t ing up t he init ial developm ent environm ent ent ails m ost of t he effort during t his act ivit y, but t he act ivit y norm ally m ust be revisit ed at t he beginning of each it erat ion. For t he sake of proj ect efficiency, it erat ions each require a level of form al t ool support appropriat e t o t he phase. For exam ple, as will be point ed out in great er det ail, t he rigor of CCM and t he t est support required will increase wit h t he num ber of it erat ions. Enabling t hese feat ures t oo early can, in fact , severely hinder developm ent . The t ools environm ent will be configured successively t o enable, or even t o enforce, t he appropriat e rigor as t he proj ect progresses.

Con figu r a t ion a n d Ch a n ge M a n a ge m e n t W or k flow ( CCM W or k flow ) CCM is a support ing workflow t hat accom panies t he ent ire crit ical developm ent pat h and it s t ools. The requirem ent s m anagem ent act ivit y ( discussed previously) handles change m anagem ent from t he perspect ive change request s and t he flow of t hese request s in t he I T organizat ion. CCM addresses t he environm ent and m echanism s t o t echnically m anage t he art ifact s produced and changed wit hin t he I T organizat ion, m ost not ably by syst em developm ent proj ect s. CCM is concerned prim arily wit h effect ively part it ioning, versioning, and archiving art ifact s t hroughout t he developm ent life cycle. This requires a dedicat ed, highly t echnical workflow. For t his support ing workflow, t he Convergent Archit ect ure leverages UCM, as recom m ended by RUP ( Krucht en 1998) . This sect ion describes how special art ifact t ypes are handled in t he UCM cont ext . These are t he art ifact s t hat are specific t o t he archit ect ural st yle and, as such, are not covered as part of t he st andard UCM workflow guidelines.

ƒ ƒ ƒ ƒ ƒ

Since t he CCM environm ent m anages art ifact s at t he t echnical level, it is also close t o t he physical environm ent ; it m ust deal wit h t he diverse st orage requirem ent s of t ools, fram eworks, and operat ing syst em s. I n fact , t he archit ect ural I DE leverages t he CCM environm ent t o help insulat e it from t he idiosyncrasies of t he low- level physical environm ent . The Convergent Archit ect ure Web sit e provides exam ples t o help set up and m anage CCM environm ent s in conj unct ion w it h t he archit ect ural I DE and for large developm ent t eam s. Act ivit y. Act ivat e UCM ( m anage CA- specific art ifact s in a UCM workflow) . Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Assem bly developer, configurat ion m anager, reposit ory t oolsm it h, developer, or ot her worker requiring t he CCM environm ent . Ar t ifa ct s pr oduce d or r e fine d. Assem bly configurat ion m anagem ent reference, UCM reposit ory. Ot he r e nd r e sult s. Proj ect - specific versioning and archiving of art ifact s. Guide line s a nd a r t ifa ct / t ool usa ge : This act ivit y m ay com m ence any t im e aft er t he developm ent environm ent workflow has inst alled and t est ed t he basic UCM infrast ruct ure. However, it norm ally does not st art unt il t he second it erat ion of t he proj ect or even lat er. This is so because t he UCM m odel, procedures, and t ools are designed t o m anage relat ively st able art ifact t opologies, not t o handle rapid changes in t opologies. The init ial phase of a proj ect is called t he incept ion phase for a good reason: Much of t he t opology is

-178-

Convergent Architecture

Chapter 6: The Development Process

not known yet . During t he init ial it erat ions, a t eam is rapidly invent ing, creat ing, and concurrent ly changing t he com ponent and package t opology. Art ifact s are changed and exchanged m any t im es a day bet ween t he m em bers of t he proj ect . Experience shows t hat t rying t o int roduce t he com plet e UCM m odel t oo early result s in hindering t his dynam ic t eam process due t o t he adm inist rat ive overhead required t o m ake changes. I n t he init ial it erat ion, a canonical proj ect t eam m ay go t hrough 10 or 20 UCM cycles ( int egrat ionbaseline cycles) per day. At t his st age of a proj ect , t his am ount s t o high t im e consum pt ion wit h essent ially zero ret urns. Thus, t his act ivit y usually st art s lat er, at t he discret ion of t he assem bly developer, who will know when t he com ponent t opology and ot her art ifact s can be m anaged reasonably using t he UCM m odel. Up t o t his point , a basic client - server version cont rol syst em , for exam ple, a basic ClearCase infrast ruct ure, is t he best bet . Sim ilar t o ot her support ing act ivit ies, t he UCM act ivit y is also a t eam effort , where t he developer helps specify and set up his or her local UCM environm ent while learning and pract icing it s use. To ensure t hat t he UCM part it ioning is coordinat ed across t he ent ire proj ect as well as wit h ot her proj ect s, t he assem bly developer part icipat es in t his act ivit y. The assem bly developer works wit h t he developer t o define t he UCM cont ent s and st ruct ure and t he UCM views, access right s, responsibilit ies, and ownership issues. This t ask m ust be lead by t he assem bly developer because it has a lot t o do wit h proj ect planning and design foresight : I m proper part it ioning and assignm ent of art ifact s at t his st age will invariably lead t o confusion and frict ion in t he developm ent effort . During t his t ask, t he configurat ion decisions are m ade in accordance wit h guidelines in t he assem bly configurat ion m anagem ent reference or serve t o ext end t hese guidelines t o handle a special case. The init ial assem bly configurat ion m anagem ent reference is creat ed by t he assem bly developer based on t he t em plat e provided by t he configurat ion m anager. This ensures m axim um CCM uniform it y across proj ect s. At t he end of t his act ivit y, t he assem bly developer creat es a new version of t he assem bly configurat ion m anagem ent reference. I n addit ion t o versioned art ifact s, t he t eam ident ifies archived art ifact s. Archived art ifact s are t hose ent it ies t hat cannot , or should not , be handled by t he UCM reposit ory direct ly. These are t hings such as handbooks t hat do not exist in elect ronic form or t hings such as soft ware inst allat ion CDs t hat would unduly burden t he UCM reposit ory. Such archived art ifact s norm ally are represent ed as versioned proxy art ifact s ( also known as reference art ifact s) wit hin t he versioned UCM pool. Managing versioned proxies of t he archive art ifact s enables a labeled release t o be m anaged in t he UCM syst em w it hout losing t rack of t he relevant archived art ifact s. Figure 6.7 illust rat es t he special t ypes of art ifact s produced along t he CA process workflows using t he archit ect ural I DE. These art ifact s lie in t he crit ical developm ent pat h and need t o be under UCM m anagem ent . Following t he figure, I explain how each of t hese art ifact s norm ally should be handled in t he cont ext of t he I T organizat ion and it s canonical developm ent t eam . Before covering each art ifact , it is im port ant t o not e t hat we do not need t o version purely generat ed art ifact s in t he UCM pool. I nst ead, we only version and m anage t he source art ifact s t hat are used t o generat e t hese other art ifact s. The except ion t o t his is at t he end of an it erat ion, where t he released assem bly, including all generat ed and deployable art ifact s, is versioned and labeled. Since t he Convergent Archit ect ure focuses on a m odel- driven approach along t he ent ire life cycle, significant ly fewer art ifact s m ust be m anaged as com pared wit h t radit ional developm ent environm ent s.

-179-

Convergent Architecture

ƒ

ƒ

ƒ

ƒ

ƒ

Chapter 6: The Development Process

Figure 6.7 shows t he evolut ion ( m et am orphosis) of a convergent m odel t hrough t he workflows of t he CA process and t he special t ypes of art ifact s creat ed using t he archit ect ural I DE during each workflow. The following list describes t he art ifact s t hat m ust be UCM- coordinat ed am ong part icipant s in t he canonical developm ent t eam . The design int ernals of t hese art ifact s will be discussed in m ore det ail in Chapt er 7. r e pos- UM L/ XM L, pr j / X M L. The repos- UML/ XML is t he UML reposit ory t hat m anages t he convergent m odel across all st ages of developm ent and across t he various t ool m odules t hat operat e on t he UML represent at ion of convergent com ponent s. The XML signifies t hat im port - export and part it ioning of t he m odel am ong developers is achieved via XML/ XMI - form at t ed m odules. These XML part it ions are unit s t hat m ay be m anaged on a per- developer basis in t he UCM pool. I n addit ion, t he I DE configurat ions for t he t eam and for each developer are m anaged in a XML proj ect file, prj / XML. At som e st age, t his proj ect configurat ion inform at ion also will need t o be in t he versioned UCM pool. m dl, ca t , sub, pr p. Beginning wit h t he convergent refinem ent I I I act ivit y of t he ABD workflow, t he I DE em beds Rat ional Rose as a foundat ion for it s UML com plet ion assist ant s. This produces addit ional Rose- specific art ifact s t o support t eam developm ent using Rose. These art ifact s are t he ASCI I m odel files m dl, cat egory files cat , subsy st em files sub, and m odel propert ies files prp. You will see in t he next chapt er how t hese art ifact s relat e t o t he UML/ XML reposit ory. These art ifact s also will ent er t he versioned pool on a t eam and a per- developer basis as soon as t he part it ioning of t he m odel has st abilized. t pl, py. Som e proj ect s require ext ensions or m odificat ions t o t he default t echnology proj ect ion cart ridges. These ext ensions norm ally are in t he form of m et aprogram s consist ing of t em plat e files t pl or JPyt hon script s py t hat have been developed and t est ed in t he t ranslat ive generat or I DE. These ext ensions m ust be versioned in t he UCM pool t o coordinat e t hem wit h ot her versioned art ifact s t hat require t hese generat or ext ensions. j px . To support t he im plem ent at ion cycle workflow, t he I DE em beds JBuilder for com plet ion, com pilat ion, and t est ing of t he business dim ension. To support t hese act ivit ies, JBuilder- specific proj ect files in XML j px are generat ed from t he UML m odel. I f t hese art ifact s are m odified above and beyond t heir purely generat ed aspect s, t hey t oo m ust be versioned sim ilar t o t he proj ect specific configurat ion files. W EB- W AR, EJB- JAR, Clie n t - JAR, UTe st - JAR, ATe st - JAR, EAR. For t he im plem ent at ion cycle, t est , and deploym ent workflows, t he t ranslat ive generat or produces source code ( for exam ple, Java, C+ + , COBOL, XML, HTML) , configurat ion files, deploym ent descript ors, build environm ent files, and t est ut ilit ies. I t also produces inform at ion t o package t hese art ifact s as deployable unit s. These deployable unit s are t he JAR ( Java archive) files show n in t he figure, which t oget her com prise t he assem bly. The assem bly is packaged as an ent erprise archive ( EAR) file. Any of t hese files m ay cont ain st yle- conform refinem ent s by t he developer above and beyond t heir generat ed cont ent . Any of t hese art ifact s t hat deviat e from t heir generat ed form m ust ent er t he versioned pool.

Ana lysis- by- D e sign ( ABD ) W or k flow The concept of analysis by design is cent ral in convergent engineering, and as applied here, it consolidat es t he RUP act ivit ies of business m odeling, requirem ent s

-180-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ ƒ ƒ

TE

ƒ

analysis, and design act ivit ies. The analysis- by- design workflow is divided int o t hree phases, each represent ing a crit ical refinem ent st age along t he m et am orphosis from a rough business st rat egy int o t he OPRs of a convergent syst em . Each act ivit y of t he workflow covers one of t hese t hree phases: Conve r ge n t r e fine m e nt I ( conve r ge nt busine ss m ode ling) . This begins wit h t he result s from t he T- bar business analysis act ivit y and produces a verified business obj ect m odel, including it s use- case scenario m odels using t he C- BOM m odule of t he archit ect ural I DE. Conve r ge n t r e fine m e nt I I ( con ve r ge nt UM L r e pr e se nt a t ion ) . This begins wit h t he result s from convergent refinem ent I and produces an init ial convergent UML m odel using t he C- RAS m odule of t he archit ect ural I DE. Conve r ge n t r e fine m e nt I I I ( conve r ge nt UM L com ple t ion ) . This begins wit h t he result s from convergent refinem ent I I and produces a fully elaborat ed UML m odel using t he C- REF/ Rose m odule of t he archit ect ural I DE. Act ivit y. Convergent refinem ent I ( convergent business m odeling) . Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Assem bly developer, dom ain expert s, lead developers. Ar t ifa ct s pr oduce d or r e fine d. Convergent business obj ect m odel, refined cont ext diagram s. Guide line s a nd a r t ifa ct / t ool usa ge : The first act ivit y in t he t hree- phase refinem ent process is known as convergent business m odeling or sim ply convergent refinem ent I . The only prerequisit e is t he result s from t he T- bar business analysis act ivit y. The refinem ent act ivit y t akes high- level T- bar business m odels and requirem ent s and refines t hem int o a t est ed convergent business obj ect m odel t hat includes bot h st ruct ural and dynam ic det ail. I t uses t he C- BOM and UML m odel reposit ory m odules of t he archit ect ural I DE t o support t his act ivit y and t o m anage t he result ing art ifact s. I n t his act ivit y, t he assem bly developer organizes business m odeling sessions wit h lead developers and dom ain expert s according t o t he convergent engineering approach ( Taylor 1995) . These sessions are, in m any ways, sim ilar t o t he T- bar sessions described earlier. At t his st age, t he focus is on furt her refining part s of t he T- bar result s, as defined in t he proj ect proposal and current it erat ion plan. First , business use- case scenarios ( BUCS) and accessor use- case scenarios ( AUCS) are creat ed. These scenarios pick up where t he t op- level scenarios from T- bar act ivit y leave off. These are norm ally t ext ual scenarios. BUCS describe business operat ions, independent of t he part icular user or syst em access m echanism s. I f required ( discussed lat er) , AUCS add scenarios specific t o one or m ore access channels from t he perspect ive of an ext ernal user or an ext ernal syst em . The AUCS sim ply specify t he st ruct ure and int eract ion aspect s of each of t he accessor's represent ers ( an access channel) from t he perspect ive of t he user. I t t akes a flat perspect ive: I t j ust t alks about how t he user int eract s via t he part icular represent er; it does not cover t he business logic st ream behind t he scenes, which is covered by t he BUCS. The AUCS m ay refer t o one or m ore BUCS, of course. Once init ial, first - cut BUCS and AUCS exist , t he rest of t he act ivit y proceeds as illust rat ed in Figure 6.8. This approach is sum m arized following t he diagram ; det ails and ext ensive exam ples m ay be found in t he convergent engineering reference ( Taylor 1995) . Det ails regarding t he C- BOM t ool support and m odeling st yle are also covered in subsequent chapt ers.

AM FL Y

ƒ

Chapter 6: The Development Process

ƒ

-181-

Team-Fly®

Convergent Architecture

ƒ

ƒ

Chapter 6: The Development Process

Figur e 6 .8 : Recording and verifying business designs. Role playing verifies and debugs t he design and achieves consensus wit h dom ain expert s regarding requirem ent s and priorit ies. I n a t alk- t hrough, t he developers discuss a scenario, st ep by st ep, wit h t he dom ain expert s. Along t he way, convergent com ponent s are ident ified and recorded as CRC cards wit h t heir respect ive responsibilit ies and collaborat ors in t he m odel. During t his process, t he business use- case scenario is also refined int o a use- case scenario m odel ( scenario m odel) , a visual represent at ion of t he dynam ic business flow and t ransit ions bet ween t he convergent com ponent s. Scenario m odels only need t o be creat ed for BUCS; t he accessor use- case scenarios are furt her refined in st ep 3 of t he refinem ent process. The responsibilit ies on each CRC card are cat egorized in t erm s of visible and hidden responsibilit ies, corresponding t o t hings of int ernal, privat e nat ure t o t he business com ponent or t hings t hat m ust be exposed t o collaborat ors of t he com ponent . I n addit ion, each responsibilit y is allocat ed t o one of t he following t hree responsibilit ies cat egories:

o

Know ing. These are passive inform at ion ent it ies held or referenced by t he business obj ect , an address or account num ber, for exam ple.

o

D oin g. These are act ive procedures or algorit hm s carried out by t he business obj ect , t he act of t ransferring funds, for exam ple.

o

En for cin g. These are precondit ions, post condit ions, and invariant s t hat m ust be ensured by t he business obj ect . An exam ple here would be an invariant indicat ing t hat a client cannot also be a m em ber of st aff. These cat egories are not always ort hogonal in nat ure. This m eans t hat one m ay be expressed in t erm s of anot her—responsibilit ies are, aft er all, writ t en in hum an language. For exam ple, one could express a responsibilit y for enforcing t he cust om er's good st anding in t erm s of one doing a check on a cust om er's good st anding inst ead. However, it is oft en easy t o cat egorize t he responsibilit ies, especially wit h som e experience. Also, t he nonort hogonalit y is not a crit ical problem at t his point in design: The focus of t his level of design is on high- qualit y business requirem ent s, not on 100- percent ort hogonalit y of represent at ion. Using t hese cat egories st ill helps sim plify and st ream line t he pat t ern- m at ching process in subsequent act ivit ies. Refer t o t he OPEN t oolbox of t echniques ( Henderson- Sellers 1998) if you require m ore background on t hese t hree cat egories. I n a walk- t hrough, a RUP- com pliant role- playing t echnique is used t o furt her refine and check t he com plet eness and business

ƒ

ƒ

-182-

Convergent Architecture

ƒ

ƒ

ƒ

ƒ ƒ ƒ ƒ ƒ

Chapter 6: The Development Process

relevance of t he m odel. A walk- t hrough oft en result s in changes t o opt im ize t he m odel. Several w alk- t hroughs m ay be required unt il t he ent ire t eam , which represent s bot h business and syst em perspect ives of t he convergent m odel, is sat isfied wit h t he operat ional im provem ent s and t he feasibilit y of t he m odel. Not only is each walk- t hrough a refinem ent and opt im izat ion st ep, but it is also a debugging and sanit y- check procedure. To ensure t hat all t eam m em bers concur on t he qualit y of t he m odel, a run- t hrough m ust be com plet ed and recorded. I n a runt hrough, t he t eam runs t hrough t he scenario m odels, including each separat ely m odeled pat h. A run- t hrough is successful when no m ore errors are found, and all part ies are sat isfied wit h t he cont ent and qualit y of t he m odel. Thus, t his st ep represent s a sanit y- verificat ion and consensus check. Each run- t hrough produces a st at e- t ransit ion t able t hat docum ent s each of t he respect ive pat hs t hrough t he convergent m odel. The result s of t he run- t hrough are recorded t oget her wit h t he CRC and scenario m odels. The t hree st eps—t alk- t hrough, walk- t hrough, and runt hrough—are repeat ed for a num ber of pat hs t hrough t he business operat ion and m odel, not j ust a single best - case pat h. The recorded result s of each pat h define t he accept ance t est s for t he result ing convergent syst em . They also serve as a signoff docum ent for t he lifecycle obj ect ive ( LCO) m ilest one of t he proj ect . I n t his act ivit y, accessors m ay be m odeled in t he form of CRC cards wit h associat ed accessor use- case scenarios. However, since accessors are not core business obj ect s, t hey do not have t o appear in t he business m odel. Oft en, accessors are int roduced int o t he m odel in t he t hird refinem ent st age, t he pure UML st age. This is m ore effect ive because, once in t he UML st age of refinem ent , default accessors and m any aspect s of cust om accessors can be derived aut om at ically from t he business com ponent m odel. Many accessor m odels can be generat ed aut om at ically from t he business com ponent m odel once t he UML st age has been reached. The decision is whet her accessors should be det ailed and docum ent ed in refinem ent phases I and I I , t he ext ent of det ailing being left t o t he discret ion of t he assem bly developer. By default , I recom m end beginning wit h t he aut om at ic generat ion of accessor m odels in phase I I I of refinem ent . Act ivit y. Convergent refinem ent I I ( convergent UML represent at ion) . Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Assem bly developer, lead developers. Ar t ifa ct s pr oduce d or r e fine d. Pat t ern- refined convergent business obj ect m odel. Guide line s a nd a r t ifa ct / t ool usa ge : This second act ivit y in t he t hree- phase refinem ent process is also called convergent UML represent at ion because it com plem ent s t he business dim ension wit h t he st ruct ures t o effect ively represent bot h business and I T dim ensions in UML. I n t his act ivit y, t he developer or developers from Convergent Refinem ent I sessions refine t heir result s int o a convergent UML m odel. Pat t erns from t he OPEN Consort ium ( Henderson- Sellers 1998) are used t o help ensure t hat t rackable convergence t akes place and t hat uniform refinem ent st yle is est ablished across proj ect s. Sim ilar t o t he previous act ivit y, t his is a creat ive design process t hat cannot be 100 percent aut om at ed; however, it can be

-183-

Convergent Architecture

ƒ

ƒ

ƒ ƒ ƒ ƒ ƒ

ƒ

ƒ

Chapter 6: The Development Process

part ially aut om at ed and significant ly support ed by an int elligent t ool. This support is provided by t he C- RAS m odule of t he archit ect ural I DE, which assist s t he designer w it h t he process of pat t ern- driven refinem ent , design st yle checks, and ot her checks for com plet eness and qualit y. Det ails regarding t he C- RAS t ool support and t he relevant aspect s of t he m odeling st yle are covered in subsequent chapt ers. I n part icular, an exam ple of t he OPEN refinem ent pat t erns is shown in t he C- RAS sect ion of Chapt er 7. I n t his act ivit y, t he developer st eps t hrough t he convergent business obj ect m odel and refines each of t he recorded responsibilit ies and collaborat ions of a CRC card. Each responsibilit y and collaborat or is explicit ly assigned a UML represent at ion according t o t he defined ( or configured in t he case of a t ool) UML m odeling st yle. How such assignm ent t akes place is det erm ined by pat t erns m ent ioned earlier. The explicit assignm ent in t he I DE according t o pat t erns perm it s bidirect ional t rackabilit y and convergence bet ween t he refinem ent st ages. Aft er com plet ion of t his act ivit y, t he m odel has been det ailed and part it ioned t o t he point where t he assem bly developer can m ake effect ive assignm ent s concerning resource ownership in due course of t he proj ect m anagem ent workflow. Thus, at t his point , furt her st ages of refinem ent and im plem ent at ion m ay be assigned t o a num ber of com ponent developm ent t eam s. Act ivit y. Convergent refinem ent I I I ( convergent UML com plet ion) . Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Lead developer, accessor developer, CEG. Ar t ifa ct s pr oduce d or r e fine d. The UML m odel of convergent com ponent s has been refined and verified t o t he level of t echnical feasibilit y for a specific t echnology proj ect ion. Guide line s a nd a r t ifa ct / t ool usa ge : The t hird act ivit y in t he t hree- phase refinem ent process is known as convergent UML com plet ion because it result s in a UML represent at ion t hat is com plet e enough t o support aut om at ic t echnology proj ect ion int o a deployable syst em . To achieve t his, t he lead developers and accessor developers use t he m odeling st yle for one or m ore t echnology proj ect ions. This process of com plet ion is act ively support ed by t he C- REF m odule of t he archit ect ural I DE in conj unct ion wit h t echnology proj ect ion cart ridges and t heir respect ive m odel verifiers. The canonical developm ent t eam st art s by agreeing, t oget her wit h t he assem bly developer, on t he part it ioning and unique ownership of t he convergent com ponent s if not already com plet ed in t he previous phase. Accessors are usually allocat ed t o accessor developers and ot her convergent com ponent s dist ribut ed am ong com ponent developers. The relat ive responsibilit ies and int eract ion bet ween t hese t eam m em bers and ot her part icipant s in t he t eam follow t he logic defined in t he I T- organizat ion m odel. Once t he developer knows which convergent com ponent s he or she is responsible for ( resource owner) , refinem ent can begin in t he CREF/ Rose m odule. The first t hing t hat t he developer will not ice on opening t he det ailed UML view is t hat m uch of t he UML m odel has been com plet ed behind t he scenes by t he archit ect ural I DE. The I DE has accom panied each st ep of refinem ent wit h an aut om at ic m et am orphosis of t he com ponent s according t o t he m odeling st yle. I n ot her words, t he creat ive input of t he developer t hus far has been used by t he archit ect ural I DE t o derive ot her m odels and propert ies. The developers now cont inue w it h t his

-184-

Convergent Architecture

ƒ

Chapter 6: The Development Process

process of st yle- driven assist ed m odeling by set t ing key propert ies of t he m odel at t he UML level and let t ing t he I DE derive ot her m odels and propert ies. The developer should now configure a part icular t echnology proj ect ion cart ridge in t he archit ect ural I DE if t his has not already been done. As point ed out in Chapt er 4, t he t echnology proj ect ion cart ridge ext ends t he m odeling st yle wit h aspect s sensit ive t o a part icular runt im e infrast ruct ure. The I DE uses t his inform at ion t o help t he developer check or com plet e t he m odel not only at t he level of UML and J2EE/ EJB st andards ( assum ing t he default J2EE/ EJB m odeling st yle) , but also in t erm s of t he capabilit ies ( posit ive feat ures and perform ance aspect s) and const raint s ( t he problem s and lim it at ions) of t he part icular infrast ruct ure. I t also adds default s for infrast ruct ure- specific propert ies t hat can be used reasonably t o t une t he generat ed syst em from t he UML m odel.

Now t he developer proceeds t o refine t he following four areas: Business- relevant behavior ( business dim ension aspect s) from t he higher- level m odels is refined at t he UML level. For exam ple, except ions t hat were not ed in t he business scenario m odels m ay now be det ailed in t he UML m odel according t o t he m odeling st yle for except ions. Sim ilarly, t he UML- level det ails of associat ions, m ult iplicit ies, and inherit ance can now be com plet ed in det ail by t he com ponent developer. Business com ponent s are associat ed, for exam ple, not only wit h each ot her, but also wit h t heir support ing ut ilit y com ponent s in t he m odel. Exam ples of such ut ilit y com ponent s are logging sinks, specialized decoders, or device drivers. At t his point , som e proj ect s m ay want t o provide m ore det ailed docum ent at ion t o represent especially com plex sequences of com ponent int eract ions, for exam ple. To do t his, opt ional UML diagram s such as process m odel act ivit y diagram s, sequence diagram s, and ot her act ivit y diagram s m ay be creat ed in t he UML m odel. These are opt ional in nat ure because t hey are not necessary t o generat e t he deployable infrast ruct ure. 2. The accessor use- case scenarios are refined int o accessor m odels. This norm ally begins by generat ing so- called default accessor m odels based on t he exist ing business com ponent m odels. Default accessor m odels m ay be generat ed aut om at ically for com m on syst em access feat ures such as viewing com ponent s, edit ing a com ponent , querying and brow sing list s of com ponent s, and so on. Based on t hese or in addit ion t o t hese, cust om accessors can be m odeled and refined in UML according t o t he accessor m odeling st yle. 3. To address specific physical requirem ent s of t he syst em , t he I T dim ension is t uned and t he physical package st ruct ure of assem blies is defined in t he UML m odel. Physical requirem ent s concerning dist ribut ion, caching, querying, or dat abase m apping m ay all be influenced by changing t he J2EE/ EJB propert ies of t he com ponent s in t he UML m odel. Based on t he configured t echnology proj ect ion cart ridge, every com ponent has received default s for t hese propert ies. These default s m ay be changed t o t une specific aspect s of t he runt im e environm ent . During t he generat ion phase, t he t echnology proj ect ion int erpret s each of t hese t uning param et ers, including com binat orial int eract ions wit h ot her param et ers, and generat es opt im ized feat ures for t he part icular infrast ruct ure. I n addit ion t o st andard propert ies available from J2EE/ EJB, separat e propert y sheet s expose propert ies specific t o t he part icular t echnology proj ect ion. Here also, t he default s in t he UML m ay be changed t o t une t he specific added- value feat ures of t he respect ive im plem ent at ion t echnology. 1.

-185-

Convergent Architecture

Chapter 6: The Development Process

The developer t hen creat es t he assem bly m odel, which consist s of t he physical part it ioning of all ot her convergent com ponent s in t he m odel int o t he deploym ent m odules such as client - side JAR files, EJB JAR files, and Web archives ( WARs) . These are configured as physical com ponent s in t he UML m odel wit h t he help of m odeling assist ant s. Also, t he developer m ay decide t o repart it ion t he I T dim ension of a com ponent t o m eet special dist ribut ion or query requirem ent s. For exam ple, EJBdependent values m ay be split out t o t ransport t he st at e of an obj ect bet ween t he client and server personalit ies of a com ponent . Anot her such case would be t he use of a special query- ut ilit y com ponent t o increase t he perform ance of ext ensive, dist ribut ed queries. Such ut ilit y com ponent s oft en are generat ed by t he t echnology proj ect ion cart ridge t o leverage special feat ures of a part icular applicat ion server. 4. Unit and com ponent t est aspect s are m odeled or configured t o enable t he aut om at ic generat ion of t est st ruct ures and t est inst rum ent at ion. These aspect s are covered in m ore det ail in t he t est w orkflow sect ion below. I n general, t his refinem ent t akes place as a series of developm ent increm ent s, each increm ent being a com pressed it erat ion across t he rem aining workflows of t he developm ent process. I n each of t hese com pressed it erat ions, t he m odel is verified, generat ed, and t est ed using t he archit ect ural I DE t o provide t im ely feedback t o all m em bers of t he developm ent t eam . The UML m odel verifier is used frequent ly by t he developer t o check t he st yle int egrit y, com plet eness, and t echnical feasibilit y of t he m odel. Such verificat ion perm it s t he developer t o m ake m ore ext ensive changes per increm ent before having t o t raverse t he ot her workflows. Re fine m e n t Cont in uit y Acr oss W or k flow s Before m oving t o t he im plem ent at ion cycle workflow, it is im port ant t o address how cont inuit y of refinem ent is achieved in t he Convergent Archit ect ure. The visibilit y of t he business dim ension and t he I T dim ension of com ponent s ident ified and refined in t he ABD workflow is conserved in t he subsequent im plem ent at ion cycle and t est workflows. I n t hese w orkflows, refinem ent occurs in Java ( or C+ + , COBOL, PL/ 1, and so on; Java is sim ply t he reference exam ple) using t he Java I DE in t he cont ext of t he archit ect ural I DE. I n t he Java I DE, low- level business logic is added int o t he generat ed Java infrast ruct ure. I n a convergent syst em , adding source code is st ill part of t he st ruct ured refinem ent process. The source code is anot her level of t he m odel, visibly derived from t he UML m odel. I n t he refinem ent process, t he Java- level addit ions t o t he business dim ension rem ain clearly visible and easily dist inguishable from t he generat ed business dim ension and I T dim ension aspect s. This visibilit y is achieved by using int elligent prot ect ed areas in t he Java code, as you will see in subsequent chapt ers. The prot ect ed areas allow us t o carry t he m odel- driven paradigm and t he clear separat ion of concerns int o t he code base. At t he source- code level, t he convergent com ponent is st ill clear, and it is clear which aspect s of t his com ponent were derived from t he UML m odel. Everyt hing out side a prot ect ed area is generat ed from a higher- level m odel; everyt hing wit hin t he prot ect ed area is specified at t he Java level of t he m odel. The m et am orphosis of t he com ponent is st ill visible: The m odel- driven approach does not dissipat e when one get s t o source code.

-186-

Convergent Architecture

Chapter 6: The Development Process

Each level of refinem ent and each view of t he m odel, including it s Java view, has it s j ust ificat ion as a st ruct ured st ep in convergent refinem ent . This is because im port ant t hings cannot be represent ed in UML. UML is, aft er all, j ust a level of abst ract ion. I f we t ried t o represent everything in UML, t hen it would be j ust as com plex as t he m achine code generat ed by com pilers. Som e aspect s of t he business dim ension are best underst ood and represent ed at t he Java level of t he m odel, som e are best underst ood and expressed furt her upst ream in t he UML m odel, and ot hers are best underst ood and form ulat ed as CRC cards in t he t oplevel business m odel. The aspect s best represent ed in Java are t he low- level " if, t hen, else" aspect s of business logic. This logic im plem ent s, for exam ple, t he condit ional t ransit ions t hat we capt ured upst ream in t he BOM scenario m odels or t he com plex algorit hm ic aspect s of responsibilit ies described in t he CRC cards. I n t he Convergent Archit ect ure, t he Java ( or C+ + , COBOL) com piler is view ed as j ust one of m any m odel- driven aut om at ion st eps. For exam ple, t he generat or and t echnology proj ect ion cart ridge ( for one or m ore t echnologies) is used t o get from t he UML m odel t o t he Java level of t he m odel, and t he com piler ( for one or m ore plat form s) is used t o get t o t he next level below Java. I n fact , t here are addit ional aut om at ion st eps. On deploying an assem bly, for exam ple, t he applicat ion server also generat es m asses of new code behind t he curt ain in order t o com plet e t he I T dim ension in t he cont ext of t he part icular applicat ion- server environm ent . This applicat ion- server- specific aut om at ion st ep is driven by t hings ( deploym ent descript ors and Java, for exam ple) generat ed by t he t echnology proj ect ion cart ridge, which, in t urn, is driven by t he UML m odel. To sum m arize t he cont inuit y across workflows, it can be said t hat t he m odel- driven developm ent of a convergent syst em consist s of a series of repeat able, st yledriven st ages of refinem ent and aut om at ion ( m et am orphosis) t hat begin wit h business m odeling and progress consecut ively t hrough t o t he final runt im e syst em .

I m ple m e n t a t ion Cycle W or k flow The im plem ent at ion cycle workflow describes t he st eps required during t he st age of developm ent following t he ABD workflow. I t is called a cycle because it is repeat ed quit e oft en, beginning wit h t he enhancem ent phase of a proj ect and increasing in frequency t hrough t he it erat ions of t he const ruct ion phase. The im plem ent at ion cycle begins in t he Convergent Archit ect ure w it h a m ouse click. Based on t he m odels developed in t he ABD w orkflow, t he generat or m odule of t he archit ect ural I DE now t akes over and generat es som ewhere bet ween 50 and 90 percent of t he environm ent required t o build, t est , and deploy t he syst em furt her downst ream . The int egrit y of t he generat ed code is t he responsibilit y of t he t echnology proj ect ion com ponent ( see Chapt er 4 and t he bonus chapt er on t he Web sit e) . The rem aining percent of t he syst em is low- level logic t hat is filled int o t he generat ed infrast ruct ure by t he developer. The environm ent generat ed from t he UML m odel can be built , deployed, and t est ed im m ediat ely. However, since t he Java- level business logic has not yet been im plem ent ed, m any business- relevant feat ures w ill not be com plet ely funct ional. To add t he Java- level ( or C+ + , COBOL, and so on) logic, build t he assem bly, deploy t he assem bly, and t est t he assem bly, a high- end program m ing environm ent , a Java I DE such as JBuilder, is leveraged. The com plet e configurat ion required t o leverage t he Java I DE is also generat ed from t he UML m odel. Thus, aft er generat ion, t he developer can load t he generat ed art ifact s aut om at ically int o t he Java I DE and can get down t o business im m ediat ely

-187-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ

ƒ

ƒ

ƒ

ƒ

ƒ

Chapter 6: The Development Process

com plet ing and t est ing business feat ures. The individual t asks carried out by t he developer during t his cycle are described in t he following act ivit y. Act ivit y. Model- driven im plem ent at ion cycle. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Developer, t est m anager. Ar t ifa ct s pr oduce d or r e fine d. Assem bly com ponent or convergent com ponent s as defined by t he I T organizat ion ( see Chapt er 5) depending on t he worker ( assem bly developer or com ponent developer) . Guide line s a nd a r t ifa ct / t ool usa ge : I n t his act ivit y, t he developer begins wit h result s from t he ABD workflow. These result s consist of a UML m odel t hat has been verified for t echnical feasibilit y in t he C- REF m odule of t he archit ect ural I DE. The next st ep is t o generat e t he infrast ruct ure and t he environm ent for t he im plem ent at ion cycle using t he C- GEN m odule of t he I DE. To prepare for generat ion, t he developer uses t he dialog provided t o configure det ails of t he t echnology proj ect ion cart ridges and ot her aspect s of t he proj ect environm ent . For exam ple, in addit ion t o checking t he configurat ion of t he applicat ion server it self, t he developer ent ers inform at ion pert aining t o t he dat abase or persist ent st orage environm ent , t he Java I DE environm ent , and t he current operat ing syst em environm ent . The developer t hen select s t he UML m odel and act ivat es t he generat or from t he UML environm ent . I ndividual part s of t he UML m odel or part s of t he t echnology proj ect ion m ay be select ed for generat ion. For exam ple, t o select ively generat e t he Web accessors, only t he accessor cart ridge is select ed, and all t he ot her cart ridges are deselect ed for t he generat ion run. Once t he generat or is finished, t he developer sw it ches t o t he Java I DE and loads t he generat ed proj ect file ( if t his has not already been done by t he Java I DE) . At t his point , t he com pile, build, and t est cycle can be st art ed right away using t he generat ed infrast ruct ure. This perm it s t he developer t o im m ediat ely t est aspect s derived from t he UML m odel in t he runt im e environm ent . However, t he business dim ension is st ill incom plet e, so not m uch business logic can be t est ed yet . The next st ep is t o com plet e t he business dim ension in t he Java I DE. To com plet e t he business dim ension and it s int eract ion wit h t he I T dim ension, t he developer edit s prot ect ed areas t hat were generat ed int o t he Java/ J2EE infrast ruct ure. The locat ion of t hese prot ect ed areas is also derived from t he UML m odel. Depending on t he qualit y and coverage of t he m odeling st yle and t he t echnology proj ect ion cart ridges ( or ext ensions t o t hese, respect ively) , t he developer m ay have t o edit prot ect ed areas wit hin t he I T dim ension. I n any case, anyt hing writ t en wit hin t he boundaries of prot ect ed areas rem ains unchanged across repeat ed generat ion runs. I m plem ent at ion guidelines for hand coding also exist . These are t he sent inels ( see Chapt er 7) t hat are defined or designat ed by t he chief archit ect t o govern t he archit ect ure- conform usage of cert ain t echnologies as required by t he local inst ance of t he Convergent Archit ect ure. The default sent inel for t he Java developm ent kit , for exam ple, cont ains a reference t o widely accept ed Java coding convent ions found at j ava.sun.com / docs/ codeconv/ . Ensuring t he t est abilit y of t he com ponent s is a norm al part of t he im plem ent at ion cycle workflow. Bot h unit t est s and com ponent t est s are creat ed and m aint ained by t he developer as part of each convergent com ponent . Sim ilar t o ot her art ifact s, significant part s of t hese

-188-

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 6: The Development Process

t est art ifact s can be generat ed from t he UML m odel and com plet ed in t he Java I DE. The t est workflow described lat er provides m ore inform at ion on t est art ifact s. At t his point , t he developer begins a rapid design and im plem ent at ion cycle. Each cycle consist s of an increm ent al increase in syst em capabilit y and it s com m ensurat e t est feat ures. I n each cycle, t he developer m oves back t o t he UML m odel, changes or ext ends t he m odel, and regenerat es t he respect ive infrast ruct ure. [ 3] The developer t hen proceeds t o t he Java I DE t o add m ore cust om code t o t he com ponent and it s t est art ifact s. The Java I DE is used t o aut om at ically com pile, build, deploy, and run t he com ponent s, including t he accessor s. The developer t hen runs t he accessors and t he t est art ifact s in t he Java I DE t o check t he business and t echnical feat ures of t he syst em and t o t race and debug any problem s int roduced during cust om coding. I n t he lat er it erat ion or t he const ruct ion phase, edit ing m ay be unnecessary. The developer or t est ers m ay want t o regenerat e, build, and t est t he syst em wit hout accessing t he UML t ool or t he Java I DE. This is especially t rue for aut om at ic t est s of assem blies and com ponent s, where ent ire m odels are checked out direct ly from t he UCM pool and t hen generat ed, built , deployed, and t est ed wit hout hum an int ervent ion. Such aut om at ic t est s will be carried out on a regular basis, night ly, for exam ple, once t he proj ect has m at ured well int o t he const ruct ion phase. To support t he large- scale aut om at ic t est ing of com ponent s, infrast ruct ure, and t ools, t he t echnology proj ect ion cart ridges also generat e com m and- line script s t o carry out t he cycle. Based on t hese script s, com m and- line processing can be st art ed by calling t he generat or ( C- GEN m odule) from t he com m and line t o access t he UML m odel ( via t he C- REF m odule) and generat e t he infrast ruct ure. The script s also provide com m and- line com m ands for t he rest of t he com pile, build, deploy, and t est cycles. The level of support for t hese phases depends, of course, on t he part icular t echnology proj ect ion cart ridge. Developers m ay need t o m odify or ext end t he capabilit ies of t echnology proj ect ion cart ridges. This is done using t he generat or I DE m odule of t he archit ect ural I DE. A sim ple m odificat ion t hat is frequent ly m ade t o a cart ridge is, for exam ple, t o add t he corporat e logo and ot her graphics t o t he default HTML represent ers. As explained in Chapt er 4, t he HTML represent er is t he HTML front end generat ed by a cart ridge. To m odify t he graphic design produced every t im e t he generat or is run, a developer or developm ent t ool expert m ay edit , t est , and debug t he new graphic design using t he generat or I DE. Once t est ed, t his cart ridge change m ay becom e part of t he default cart ridge t o be used by all ot her proj ect s. However, such changes t o cart ridges should only be m ade wit h consent of t he chief archit ect . More det ails concerning t he cont ent of cart ridges and t heir relat ionship t o t he archit ect ural I DE are provided in t he next t wo chapt ers. [ 3]

The desirable side effect of t his cycle is t hat t he design is alw ays in sync w it h t he im plem ent at ion, t he int egrit y of t he design is im m ediat ely verified at t he UML level, and t he syst em design is im plicit ly docum ent ed in UML.

-189-

Convergent Architecture

Chapter 6: The Development Process

Te st W or k flow A m at ure m odel- driven approach significant ly reduces t he am ount of code t hat m ust be t est ed. However, at least t hree good reasons rem ain as t o why effect ive t est coverage is needed. First , even t he best UML m odels and t heir t echnology proj ect ions are not form al proof t hat t he generat ed syst em will w ork as expect ed. Mat ure m odeling and well- t est ed t echnology proj ect ion cart ridges do reduce t he source of error significant ly, but one is never 100- percent sure unt il t he syst em is t est ed. This uncert aint y is inherent in t he com plexit y of applicat ion- server and net w orked- syst em environm ent s. Clearly, t hese servers and environm ent s are t hem selves not wit hout error. Second, any m odels and code ent ered by hum ans during t he im plem ent at ion workflow are subj ect t o hum an oversight . Test ing is t he only effect ive w ay t o check t heir correct ness. Third, and m ost significant , we need t o verify t hat t he business represent at ion, t he business dim ension, is really doing what we said it w ould. No m at t er how good we are at reducing errors, t here will always be residual uncert aint ies—in t he foreseeable fut ure anyw ay—t hat can be reduced furt her only t hrough adequat e t est ing. The archit ect ural st yle deals wit h t his realit y by encom passing a t est workflow and it s respect ive organizat ional and t ool support . Here again, t he m odel- driven approach affords t he m ost effect ive t est coverage. Figure 6.9 illust rat es t his approach as support ed by t he archit ect ural I DE. To t he left are t he UML m odels t hat conform t o a well- defined m odeling st yle. Thus, significant aspect s of t he t est infrast ruct ure can be derived and generat ed aut om at ically from t he m odels. Sim ilar t o t he generat ion of default accessor m odels m ent ioned earlier, t est ing m odels also can be derived from t he business com ponent m odels—m odels used t o generat e ot her m odels. [ 4] Based on t he default t est m odels, a developer can add specialized t est ing feat ures at t he UML level. The right of t he figure shows how t est com ponent s, inst rum ent at ion, and t he aut om at ion infrast ruct ure are generat ed, as always, by way of t he t echnology proj ect ion cart ridge. The generat ed infrast ruct ure is now m odel- specific, enabling t he t est of bot h business logic and t echnical infrast ruct ure. The level of aut om at ically generat ed support for various t ypes of t est s is evolving rapidly and is, as always, dependent on t he current st at e of t he m odeling st yle and part icular t echnology proj ect ion.

-190-

Convergent Architecture

Chapter 6: The Development Process

Figur e 6 .9 : Model- driven t est infrast ruct ure. UML- driven ( OCL) t est generat ion, inst rum ent at ion, build, and runt im e.

ƒ ƒ ƒ

ƒ ƒ ƒ ƒ ƒ

AM FL Y

ƒ

Com pone n t t e st s. These aut om at e t est ing of ent ire convergent com ponent s. Asse m bly t e st s. These aut om at e t est ing of ent ire assem blies and t heir int eract ions wit h ot her assem blies ( int egrat ion t est s) .

TE

ƒ

The Convergent Archit ect ure specifies t he following t est cat egories t o enable opt im al coverage and synergies during each phase of developm ent : Unit t e st s. These aut om at e t est ing of individual t echnical unit s such as Java classes.

I nt e r a ct ion a nd r e sponse t e st s. These verify accessor use- case scenarios, user int erfaces, and response perform ance. Busine ss flow a nd conve r ge nce t e st s. These check t he fidelit y of t he syst em wit h respect t o t he business obj ect m odel. The t est developm ent and execut ion act ivit y explains t he t asks associat ed wit h each of t hese t est cat egories. Act ivit y. Test developm ent and execut ion. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Lead developer, developer, t est m anager, t est er. Ar t ifa ct s pr oduce d or r e fine d. Test m odels and environm ent , unit t est s, com ponent t est s, assem bly t est plan, assem bly t est s, assem bly t est result s report . Guide line s a nd a r t ifa ct / t ool usa ge : Once t he developer is sure t hat a part icular unit in t he UML m odel, a class, for exam ple, is relat ively long- lived, he or she creat es unit t est s t o t est t his unit in t he runt im e environm ent . The st ruct ure of t hese unit t est s m ay be m odeled in UML, or t he st ruct ure m ay be derived aut om at ically from t he m odel by t he t echnology proj ect ion cart ridge. For t he J2EE/ EJB t echnology proj ect ion, t he JUnit ( JUnit 2000) fram ework is used as a basis for t est ing, and t he ANT ( ANT 2000) fram ework is used t o

-191-

Team-Fly®

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 6: The Development Process

aut om at e t he t est s. By st ipulat ing JUnit up front in t he process, bot h m odeling st yle and t echnology proj ect ion can be t uned specifically for t his fram ework. Based on t he unit t est s, t he developer creat es com ponent t est s. Com ponent t est s are suit es of unit t est s t hat t est t he sum of t he feat ures com prising a convergent com ponent . I n addit ion t o t est ing t he I T dim ension and basic st ruct ures of t he business dim ension, business- logic t est s occur at t he com ponent t est level. The code required t o t est t he business- logic aspect s of t he com ponent is oft en as com plex as t he cust om business logic it self. As such, it is current ly added at t he Java level in t he Java I DE. However, t he basis for t hese t est s m ay be derived direct ly from t he precondit ions, post condit ions, and invariant s ent ered in t he m odel for each operat ion of t he com ponent . These condit ions and invariant s were recorded as needed in t he beginning in t he convergent refinem ent I I st age of t he ABD workflow ( using t he CREF m odule of t he archit ect ural I DE) . I f t hese precondit ions, post condit ions, and invariant s have been specified using t he Obj ect Const raint Language ( OCL) ( Warm er 1999) , t hen t hey are not only m ore concise t han nat ural language, but t hey m ay, at som e point in t he fut ure, also serve t o generat e businesslevel t est logic. Significant progress is being m ade in t he areas of form alizing OCL as part of a m odeling st yle, t hus enabling t echnology proj ect ions t o aut om at ically generat e business- level t est logic. The next level of t est ing happens at t he assem bly level. These are t he assem bly t est s. I n cont rast t o unit and com ponent t est s, which are developed cont inuously and run by developers in local t est environm ent s, assem bly t est s are specified and carried out carefully in conj unct ion wit h t he t est cent er organizat ion. Lat e in t he const ruct ion phase, t hey will be used by t he t est cent er t o t est bot h t he assem bly it self and significant int eract ions wit h ot her assem blies. The assem bly t est s are t he ult im at e level of aut om at ed t est ing. They are t he basis for regression t est ing. The result s of t he assem bly t est s carried out in t he t est cent er organizat ion det erm ine whet her an assem bly is ready t o be released int o t he t ransit ion phase. To t his end, an assem bly t est plan is creat ed by t he t est m anager t oget her wit h t he assem bly developer. The assem bly developer is t hen responsible for ensuring t hat t he assem bly is t est able according t o t his plan. For t he m ost part , t he assem bly t est consolidat es and int egrat es t he com ponent t est s. Thus, t he assem bly developer and t est m anager m ust ensure early on in t he elaborat ion phase t hat all developers are working according t o a com m on m odeling st yle for t he t est fram ework. As st at ed earlier, in t he Convergent Archit ect ure, t his m odeling st yle and fram ework current ly are based on JUnit and JUnit com pliant ext ensions for J2EE/ EJB environm ent s. Accessors t hat were m odeled and built during t he norm al course of t he ABD and im plem ent at ion cycle workflows are ext rem ely valuable t est t ools. Bot h cust om and default accessors m ay be used by hum an t est ers or by regression t est ing t ools such as Rat ional Robot t o check t wo aspect s of t he syst em . First , t hey can be used for so- called int eract ion and response t est s. These t est s can be used t o verify t he access channels defined in t he accessor use- case scenarios. More im port ant , t hey m ay be used t o t est user int eract ion qualit y and syst em perform ance. The syst em perform ance is t est ed in t his case at it s m ost relevant point —t he response t im es at t he user int erface. The aut om at ically generat ed default accessors can be used right off t he bat t o

-192-

Convergent Architecture

ƒ

Chapter 6: The Development Process

t est t he general int eract ion and response behavior of t he com ponent s wit hout having t o creat e any cust om accessors. The second aspect t est ed using accessors is t he fidelit y of t he syst em wit h respect t o t he init ial business obj ect m odel. This st ep is in fact also t est ing t he degree of convergence t hat has been achieved, so it is called business flow and convergence t est ing. During t he const ruct ion phase of t he proj ect , cust om accessors have been derived and built from t he scenario m odels developed in t he BOM. Rem em bering back t o t he ABD workflow, each scenario m odel was associat ed wit h a set of recorded runt hroughs, each docum ent ing a business- relevant pat h t hrough t he convergent syst em . The archit ect ural I DE aut om at ically docum ent s t his set of business pat hs in t he form of st at e- t ransit ion t ables. The t est er or t est recorder uses t he accessors t o t est each of t he docum ent ed pat hs t hrough one or m ore st at e- t ransit ion t ables. The result s of t hese t est s provide valuable feedback concerning t he com plet eness of t he convergent syst em , t he qualit y of t he current business dim ension, and t he ease of use of t he syst em t o support t he int ended business operat ions. [ 4]

This is equivalent t o applying pat t erns t o generat e ot her cust om ized or m ore highly specific pat t erns.

D ocum e n t a t ion W or k flow Experience has show n t hat developing qualit y, high ret urn on invest m ent ( ROI ) docum ent at ion necessit at es a dedicat ed support workflow t hat runs parallel t o t he crit ical developm ent pat h. Above all, t he sam e developers who are responsible for t he crit ical developm ent pat h cannot be expect ed t o also be expert s in docum ent at ion. Also, norm ally t hey are supposed t o apply t heir special developm ent skills t o t he crit ical pat h, not t o docum ent at ion. Producing reasonable docum ent at ion is a highly skilled j ob of it s own. Anyone wit hout t he proper skills and focus will produce poor docum ent at ion, which, in t urn, m ay cast an unj ust ified shadow on t he ent ire developm ent result s. To ensure t hat high- qualit y docum ent at ion is produced at lowest risk and lowest cost , t he Convergent Archit ect ure t akes t he following basic approach. First , t he organizat ional coordinat ion of a worker wit h t he proper skills is inst at ed in t he I T- organizat ion m odel: t he t echnical writ er. Second, t he m odel- driven approach and t he archit ect ural I DE are designed t o produce m uch of t he docum ent at ion aut om at ically as an explicit side effect of com ponent m et am orphosis. The focus on convergence in t he archit ect ure creat es an easily underst ood st ream of art ifact s t hat serves as t he syst em docum ent at ion. Clearly, if t he syst em can be generat ed from t he UML m odel, t hen t he m odel is accurat e docum ent at ion of t he syst em design. And if t he UML m odel w as visibly refined from a previous m odel, t hen w e have t he next level of design docum ent at ion, and so fort h, all t he way up t o t he highest - level business m odel. Thus, aft er st yleconform developm ent of a convergent syst em , t he art ifact s m anaged by t he archit ect ural I DE docum ent t he business design, not j ust t he syst em design—t he essence of convergence. Ot her im port ant synergies also em erge in t his const ellat ion. The developer is in fact producing a whole lot of t he docum ent at ion. The developer is essent ially unaware t hat m uch of t he docum ent at ion is being produced as a side effect of t he crit ical developm ent pat h. The approach also

-193-

Convergent Architecture

Chapter 6: The Development Process

ensures t hat t he docum ent at ion aut om at ically reflect s t he real st at e of t he design and it s result ing syst em at all t im es.

ƒ ƒ ƒ ƒ ƒ

ƒ

ƒ

ƒ

The docum ent at ion preparat ion and product ion act ivit y covered here describes t he st eps required t o ensure t he qualit y of t he design docum ent at ion and t o produce t he end- user docum ent at ion for an assem bly com ponent . Act ivit y. Docum ent at ion preparat ion and product ion act ivit y. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Technical writ er, developer, t est m anager, deploym ent m anager. Ar t ifa ct s pr oduce d or r e fine d. Docum ent at ion developm ent set , design docum ent at ion, end- user docum ent at ion. Guide line s a nd a r t ifa ct / t ool usa ge : The docum ent at ion preparat ion and product ion act ivit y is driven by t he t echnical writ er ( t he writ er) as part icipant in every canonical developm ent t eam . During t he it erat ions of t he enhancem ent phase, t he writ er begins work wit h t he assem bly developer t o develop a docum ent at ion roadm ap for t he assem bly. Then t he writ er works wit h each developer t o plan his or her cont ribut ion t o t he docum ent at ion set in each phase. When properly planned up front , t his cont ribut ion is not a part icular burden on t he developers; it sim ply specifies and coordinat es how m odels are docum ent ed. The int ent is t o im prove t he qualit y of t he m odels and t o produce m at erial for t he docum ent at ion as a side effect . The writ er ensures t hat each developer does t he following. First , for each st able m odel elem ent creat ed by t he developer, a descript ion should be ent ered in t he places provided by t he archit ect ural I DE. This includes docum ent ing precondit ions, post condit ions, invariant s, and ot her det ails of t he business dim ension and I T dim ension in t he respect ive view of t he convergent m odel. The part it ioning and st ruct ure for t hese docum ent at ion ent ries are provided by t he archit ect ural I DE. For exam ple, precondit ions and post condit ions have t heir own edit ors. I t is im port ant t o not e t hat t he developer does not have t o docum ent anyt hing already covered by t he archit ect ural st yle it self: The principles and st ruct ures of t he archit ect ure are already clear across all proj ect s, as is t he m odeling st yle and t he t echnology proj ect ion for convergent com ponent s. All t hese are already docum ent ed. The developer j ust has t o address his or her part icular usage of t he st yle. The developer and writ er can use t he verifiers in t he archit ect ural I DE t o check t hat t he elem ent s of t he m odel have been docum ent ed. Based on t he UML m odel, t he t echnology proj ect ion cart ridge generat es code wit h docum ent at ion in t he st andard JavaDoc form at . When adding cust om Java code, t he developer m ay need t o ext end t hese JavaDoc ent ries t o m ore precisely describe t he behavior. Design docum ent at ion. Once t he preceding t asks are com plet ed, t he m odels in t he archit ect ural I DE serve as am ple design docum ent at ion. I f required, special report s and special st at ist ical views of t he convergent design can be generat ed based on t he inform at ion in t he archit ect ural I DE. The inform at ion exist s and is easily accessible t hrough t he various views provided by t he archit ect ural I DE it self or by ext ernal t ools via Java and XML, for exam ple. The m odel is t he docum ent at ion of a convergent ( business and soft ware) design. I f t his is not t he case, t hen som et hing is awry because t his is one of t he principal goals of t he archit ect ural st yle.

-194-

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 6: The Development Process

The end- user docum ent at ion is a special com pilat ion and ext ension of t he design docum ent at ion for end users of t he syst em . To creat e t hese docum ent s, t he writ er derives t he basic usage of t he syst em from t he exist ing accessor m odels and t he look and feel of t he accessors t hem selves. Lit t le or no addit ional input is needed from t he developers. As part of t he end- user docum ent at ion, t he writ er begins developing t ut orials for t he end users during t he const ruct ion phase of t he proj ect . This t ask has an im port ant side effect t o furt her increase t he ROI of t he docum ent at ion workflow: The writ er is t est ing t he usabilit y of t he syst em from t he perspect ive of t he end user. By developing t ut orial docum ent at ion, t he writ er provides t he assem bly developer w it h early, im part ial feedback concerning t he usabilit y of t he syst em . The writ er also produces online help docum ent s. The enduser docum ent at ion serves as a single docum ent at ion source from which t he online help is produced aut om at ically. This is t o prevent t he online help from becom ing a branch of t he docum ent at ion t hat m ust be synchronized cont inuously w it h t he m ain t runk of docum ent at ion. Such branches are error- prone and cost ly. The single- source approach is not as sim ple as one m ight t hink but is indeed possible wit h t he reference t ools defined in t he I T- organizat ion m odel ( see Chapt er 5) . Using t hese t ools, t he online help becom es a by- product of a cent ral docum ent at ion st ream and does not const it ut e an ext ra docum ent at ion effort . As st ipulat ed in t he I T- organizat ion m odel, all proj ect s creat e docum ent at ion according t o a single docum ent at ion st yle. This st yle is defined in t he docum ent at ion developm ent set creat ed by a t echnical writ er in t he PET organizat ion during t he I T- environm ent workflow. Docum ent at ion t em plat es and st yle guides for a docum ent at ion developm ent set are publicly available for Fram eMaker, t he reference docum ent at ion t ool in t he Convergent Archit ect ure.

D e ploym e n t a nd M on it or in g W or k flow Deploym ent and m onit oring, alt hough direct ly in t he crit ical pat h, t urn out t o be fairly sim ple in t he Convergent Archit ect ure—who said it has t o be hard! This is prim arily due t o progress m ade in recent years in t he area of st andards- based applicat ion servers. When used properly, such applicat ion servers can provide a st able, high- perform ance, easy- t o- m anage plat form t hat far surpasses t hat of m any m at ure m ainfram e environm ent s.

ƒ ƒ ƒ ƒ

The t rick is not j ust t o inst all an applicat ion server, but also t o leverage t he powerful feat ures of t hese new server infrast ruct ures. Several aspect s of t he convergent com ponent s and t he archit ect ural I DE help developers and operat ors use t hese feat ures t o reduce deploym ent effort and risks while im proving t he m onit oring and adj ust m ent capabilit ies of t he syst em . The deploym ent and m onit oring act ivit y covered here describes how part icipant s on t he canonical developm ent t eam cont ribut e t o achieve t hese capabilit ies and how t he workers in t he operat ional syst em s organizat ion use t hese capabilit ies. Act ivit y. Deploym ent and m onit oring act ivit y. Act ivit y ow ne r , pr incipa l pa r t icipa nt s. Assem bly developer, deploym ent m anager, assem bly operat or, cont ainer operat or, user support specialist , com ponent developers. Ar t ifa ct s pr oduce d or r e fine d. Assem bly com ponent , applicat ion server environm ent . Guide line s a nd a r t ifa ct / t ool usa ge :

-195-

Convergent Architecture

ƒ

ƒ

o

o

o

ƒ

ƒ

Chapter 6: The Development Process

This act ivit y is driven by t he assem bly developer and begins in t he elaborat ion phase. Lat er, once t he assem bly com ponent has been deployed int o t he operat ional syst em s organizat ion, t he assem bly operat or t akes over t he responsibilit y for proact ive m onit oring and adj ust m ent of t he operat ional assem bly as well as for providing feedback t o t he assem bly developer. I n t he lat e it erat ions of t he elaborat ion phase, t he assem bly developer works w it h t he deploym ent m anager t o define t he special inst allat ion requirem ent s, m onit oring accessors, inst rum ent at ion, and m odel- driven t uning requirem ent s from t he operat ional syst em s organizat ion. As part icipant on t he canonical developm ent t eam , t he deploym ent m anager represent s t he ent ire operat ional syst em 's organizat ion and m ay solicit direct part icipat ion from ot her m em bers of t his organizat ion for t his t ask. The significant developm ent aspect s t o be addressed in t his cont ext are as follows: Above and beyond t he t ype of applicat ion server envisioned for t he operat ional environm ent , t here will be special requirem ent s and const raint s concerning t he exist ing operat ional environm ent . These requirem ent s usually will affect t he developm ent of t he assem bly inst allat ion set and m ay affect t he t uning of t he assem bly m odel at t he UML level. I n addit ion t o st andard applicat ion- server feat ures t hat are set in t he UML m odel, a part icular syst em environm ent m ay require special inst rum ent at ion t o enhance m onit oring and logging capabilit ies. This propriet ary inst rum ent at ion can be act ivat ed via a separat e m odule in a t echnology proj ect ion cart ridge for a part icular environm ent wit hout pollut ing t he st andardbased aspect s of t he UML m odel. I f t hese feat ures need t o be adj ust ed at t he UML m odel level, t hen t he m odeling st yle also can be ext ended m odularly t o expose t hese feat ures in t he UML m odel view of t he archit ect ural I DE. Special accessors and ut ilit y com ponent s m ay be desired t o allow a port able diagnosis or runt im e t uning at t he level of convergent com ponent s, regardless of t he underlying applicat ionserver infrast ruct ure or t he part icular access channel. Assem bly com ponent s are designat ed as t he int elligent deploym ent unit s in t he archit ect ure. I n t he default J2EE/ EJB t echnology proj ect ion, t hese unit s are ent erprise archives ( EARs) . I n t he case of highend J2EE/ EJB applicat ion servers, EARs m ay be deployed aut om at ically and configured int o t he J2EE/ EJB cont ainers via several pat hs, each pat h accom m odat ing a part icular phase of developm ent and it s deploym ent requirem ent s. Assem bly com ponent s can be generat ed t o support t hree deploym ent pat hs: an ANT- script - driven deploym ent t o be used for aut om at ed t est cycles ( such as assem bly t est s) , a Java- I DE- driven deploym ent t o support t he im plem ent at ion cycle workflow wit hin t he t est environm ent , and a release- level deploym ent via t he console of t he operat ional applicat ion server t o support t he t ransit ion workflow and operat ional deploym ent . Aft er release, t he st eady- st at e operat ion of t he assem bly is handled by t he assem bly operat or in coordinat ion wit h t he cont ainer operat or. Two aspect s are im port ant when considering runt im e m onit oring and t he adj ust m ent s t o an assem bly as a result of m onit oring:

-196-

Convergent Architecture

o

o

ƒ

Chapter 6: The Development Process

Som e t uning param et ers, such as EJB t ransact ion m odes and caching param et ers, which were set in t he UML m odel and generat ed int o t he runt im e infrast ruct ure, m ay be m odified in t he runt im e EJB cont ainer environm ent from t he m onit oring console. Based on changes in t he runt im e environm ent , t hese param et ers m ay require short - or long- t erm adj ust m ent s. I n t he case of long- t erm adj ust m ent s, a change is also fed back t o t he assem bly developer for a perm anent change in t he source m odel for t he next release. More im port ant , if a change in t he runt im e environm ent is dubious or uncert aint y exist s regarding it s possible side effect s, t he assem bly developer can provide proact ive, highqualit y advice based on t he originat ing UML m odel. The convergent com ponent s are visible in t he m anagem ent console of t he applicat ion server. Here again, t heir convergence wit h t he upst ream m odels sim plifies t he m onit oring and feedback channels. All st akeholders can com m unicat e rapidly and unam biguously t he source of problem s t o t he responsible organizat ions. This is so because t he convergent com ponent is visible, so it s resource owner, beginning wit h t he assem bly developer, is also clear. Also, t he com ponent in quest ion can be locat ed and inspect ed easily at any posit ion along t he developm ent st ream . This enables m ore rapid and professional responses t o problem s and suggest ions from t he field. Last ly, feat ure request s and m aj or change request s m ay arise during t he deploym ent and m onit oring act ivit y. Request s not willingly absorbed by assem bly developm ent t eam s are relayed t o t he requirem ent m anager, as described in t he global requirem ent m anagem ent act ivit y previously.

Su m m a r y This chapt er covered t he syst em developm ent process aspect of t he Convergent Archit ect ure. This is known as t he CA process and is t he t hird and last com ponent in t he developm ent m odel. The int roduct ion point ed out t he rest of t he archit ect ural st yle, which enables bot h t he opt im izat ion and sim plificat ion of t he developm ent process. This sim plificat ion is due t o t he inherent cont inuit y bet ween all elem ent s of t he st yle, a propert y referred t o as reference- fram e cont inuit y. The CA process is not a new developm ent process; inst ead, it is a derived refinem ent of several ot her m odern process fram eworks and m et hodologies. Above all, it is a st yle- specific inst ance of t he RUP ( Krucht en 1998) . I n addit ion, it w as influenced by OPEN ( Graham 1997) , EPM ( Gilb 1988/ 1999) , and cat alysis ( D'Souza 1999) .

ƒ ƒ

As an inst ance of RUP, t he CA process consist s of workflows t hat are subdivided int o act ivit ies. The workflows are organized in t erm s of t wo m aj or cat egories: Pr e pa r a t or y a n d cr oss- pr oj e ct w or k flow s. These workflows are not associat ed wit h any part icular proj ect . They are init iat ed before t he first developm ent proj ect and act in a cross- funct ional m anner across all proj ect s. Ca nonica l pr oj e ct w or k flow s. Sim ilar t o t he canonical developm ent t eam present ed in Chapt er 5, t he canonical proj ect w orkflow describes t he developm ent process from t he perspect ive of t he canonical developm ent t eam . Each of t hese cat egories was described in t erm s of t he workers involved, t he result s produced, and t he t ools used t o achieve t hese result s. I n addit ion,

-197-

Convergent Architecture

Chapter 6: The Development Process

guidelines were present ed wit hin each act ivit y out lining t he t asks carried out by each w orker and t he usage t ools em ployed t o support t he t asks. The developm ent m odel is now com plet e. The next chapt er provides det ail on how t he archit ect ural I DE support s t he developm ent m odel. The final chapt er present s a t ut orial t o show how all t he part s w ork t oget her based on a concret e exam ple using t he archit ect ural I DE. I n t his exam ple you will see how key feat ures of t he archit ect ural st yle work t oget her t o provide t angible advant ages in a real- world environm ent . I n addit ion, t he bonus chapt er on t he Web sit e provides com plet e det ails of t he t echnology proj ect ion com ponent in t he form of a reference m anual.

-198-

Convergent Architecture

Chapter 7: The Architectural IDE

Ch a pt e r 7 : Th e Ar chit e ct u r a l I D E— Au t om a t in g t h e a r ch it e ct u r e Ove r vie w The t hird and fourt h m ain feat ures of an inform at ion t echnology ( I T) archit ect ural st yle as realized by t he Convergent Archit ect ure ( refer t o Figure 1.1) are t he fullcoverage t ool suit e and t he form al t echnology proj ect ions. The focus of t his chapt er is t he t ool suit e. I n t he previous chapt ers we saw how t he archit ect ural int egrat ed developm ent environm ent ( I DE) plays a cent ral role in support ing and sim plifying various aspect s of t he Convergent Archit ect ure. Up t o t his point , t he perspect ive has been from t he various t opics of t he developm ent m odel. The support provided by t he I DE was point ed out w it h respect t o t he local t opic of each sect ion. Alt hough im port ant , t he local perspect ive does not present t he overall pict ure of how all t hese t hings work t oget her. This chapt er t akes a close look at t he sum of t he part s: t he int erdependence of t he individual pieces. I t also analyzes som e aspect s not covered from t he local perspect ives of previous chapt ers. These aspect s include t he int egrat ive and flow charact erist ics of t he archit ect ural I DE t hat enable it t o bet t er support t he archit ect ure as a whole inst ead of only covering part s of a developm ent flow. Figure 7.1 sum m arizes t he coverage of t he archit ect ural I DE wit h respect t o t he Convergent Archit ect ure ( CA) process.

Figur e 7 .1 : Archit ect ural I DE: Crit ical pat h coverage. Covering t he crit ical- pat h workflows.

ƒ

The principal obj ect ive of t he archit ect ural I DE is t o aut om at e and assist t he crit ical- pat h workflows in t he cont ext of t he ent ire developm ent m odel. I n t he figure, t he crit ical- pat h workflows are shown as t hey progress wit h t im e from left t o right . Sit uat ed below each w orkflow are m aj or cat egories of art ifact s t hat m ust be creat ed, int egrat ed, and m anipulat ed during t he workflow s. Analyzing t he figure, we can briefly sum m arize t he requirem ent s on t he archit ect ural I DE as follows: Conce r ning busine ss a nd r e quir e m e nt s m ode ls. The T- bar business analysis and requirem ent s workflow requires t ools t o easily record

-199-

Convergent Architecture

ƒ

ƒ

ƒ

Chapter 7: The Architectural IDE

and m anipulat e business st ruct ures and flow s. The m odeling act ivit ies in t his workflow are highly int eract ive. Thus, t he t ool m ust help a designer t o rapidly record and st ruct ure significant am ount s of business inform at ion wit hout hindering t he dynam ics of group- analysis sessions. The result ing m odels should t hen be equally valuable as a source of business inform at ion and for convergent refinem ent int o soft ware syst em s. Conce r ning a com m on m ode l r e posit or y. The business and requirem ent s m odels should init iat e a t rackable t hread of inform at ion and design refinem ent across all ot her workflows. To support t his t hread, bot h business and t echnical design inform at ion should be saved in a well- defined cent ral form at ( Unified Modeling Language, or UML) or com m on m odel reposit ory. This reposit ory m ust be open t o increm ent al exchange and int egrat ion at any t im e wit h ot her t ools ( XMI / XML, open Java API ) . Conce r ning UM L de sign m ode ls. The creat ion of UML m odels according t o t he analysis- by- design workflow should proceed in an aut om at ed or assist ed m anner using t he pat t erns defined by t he archit ect ural st yle. Furt her aut om at ion should help t he developer refine UML m odels according t o t he well- defined m odeling st yle. This process of t ool- assist ed m odeling should cont inue unt il t he m odel is sufficient ly com plet e t o perm it t he aut om at ic generat ion of all t hose aspect s of a soft ware syst em t hat can be reasonably represent ed in UML ( as defined by t he m odeling st yle) . To enable t he generat ion of high- value art ifact s, t he t ools m ust perm it t he developer t o aut om at ically verify and debug t he UML m odel according t o t he requirem ent s of t he m odeling st yle and t he requirem ent s of t he t arget deploym ent environm ent . Conce r ning im ple m e nt a t ion, build, de ploym e nt , a n d t e st a r t ifa ct s. Significant port ions of t hese art ifact s can be generat ed aut om at ically from any UML design m odels t hat conform t o t he m odeling st yle. This generat ion occurs according t o a t echnology proj ect ion t hat has been designed t o m ap a st yle- conform UML m odel t o a part icular t echnology. Thus, t he I DE m ust support t he pragm at ic, flexible configurat ion of t echnology proj ect ions and t heir aut om at ic use in an increm ent al developm ent process. Last ly, t he t ools m ust help developers creat e new t echnology proj ect ions or m odify and ext end exist ing t echnology proj ect ions. The rest of t his chapt er shows how an archit ect ural I DE m eet s or exceeds t hese high- level requirem ent s. I t also illust rat es t he individual feat ures of t he archit ect ural I DE t hat were referred t o in previous chapt ers on t he developm ent m odel. First , how ever, we need t o see how t he basic cat egories and requirem ent s from Figure 7.1 are m apped t o concret e m odules of a real- world archit ect ural I DE. This is done in Figure 7.2, which int roduces t he m ain m odules of t he ArcSt yler, an archit ect ural I DE as defined by t he Convergent Archit ect ure. The figure posit ions t hese m odules of t he I DE wit h respect t o t he crit ical- pat h w orkflows and t he support ing workflows of t he CA process. I t also shows som e of t he m aj or t ools t hat are current ly encapsulat ed or explicit ly coordinat ed by t he I DE: Rat ional Rose and JBuilder, J2EE/ EBJ applicat ion servers, Web infrast ruct ure, and so on.

-200-

Convergent Architecture

Chapter 7: The Architectural IDE

The following sect ions describe each of t hese m odules, one m odule per sect ion: The convergent business obj ect m odeler ( C- BOM) The federat ed UML/ XML m odel reposit ory ( C- MOD) The convergent pat t ern refinem ent assist ant ( C- RAS) The convergent UML refinem ent assist ant ( C- REF) wit h Rat ional Rose The convergent t ranslat ive generat or ( C- GEN) The convergent generat or I DE ( C- GEN- I DE) The convergent im plem ent , deploy, and t est environm ent ( C- I X) wit h JBuilder and a J2EE applicat ion server

TE

ƒ ƒ ƒ ƒ ƒ ƒ ƒ

AM FL Y

Figur e 7 .2 : The m odules and environm ent of t he archit ect ural I DE.

Since t he archit ect ural I DE covers a whole lot of ground, t he overview will be som e- what select ive. To m aint ain t he focus, each sect ion is lim it ed t o one or t wo screenshot s t hat exhibit several of t he m ost st yle- relevant feat ures of t he m odule. Based on t he screenshot , I explain how t he m odule support s t he developm ent m odel of t he archit ect ural st yle. Only t he highlight s and t he m ost crit ical feat ures are explained; m any feat ures of t he t ool m odules are not covered. Addit ional inform at ion at t he user's guide or a user's reference level is available on t he Convergent Archit ect ure Web sit e. The archit ect ural I DE leverages a specific set of best - of- breed t ools in it s st andard const ellat ion ( in part icular, Rat ional Rose and JBuilder) . These t ools were select ed t o enable t he m ost effect ive overall plat form . How ever, as a pure Java com ponent environm ent it self, t he I DE is not inext ricably coupled wit h t hese t echnologies. Alt ernat ives t o t his part icular set of em bedded t ools are conceivable.

Th e Con ve r ge n t Bu sin e ss Obj e ct M ode le r ( C- BOM ) The C- BOM m odule ( see Figure 7.3) support s bot h t he T- bar and analysis- bydesign workflow s. I t is used t o capt ure and organize t he business requirem ent s and t he business m odel. Figures 7.4 and 7.5 show it s t wo prim ary views, first t he CRC m odeling view t o capt ure t he business com ponent s and t hen t he

-201-

Team-Fly®

Convergent Architecture

Chapter 7: The Architectural IDE

corresponding scenario m odeling view t o capt ure t he business dynam ics. Toget her t hese views const it ut e a cont ract - based design.

Figur e 7 .3 : Orient at ion of t he C- BOM m odule.

Figur e 7 .4 : Business obj ect m odeling.

-202-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .5 : Use- case scenario m odeling. The t eam s in t he T- bar and analysis- by- design sessions record convergent com ponent s in t he form of CRC cards, as show n in t he figures. The CRC cards are used t o record t he business responsibilit ies, collaborat ors, privat e ownership, and inherit ance relat ionships of t he com ponent s. The t abs of each card are designed t o hold t he inform at ion on bot h docum ent at ion and special requirem ent s in areas such as securit y, m igrat ion, coordinat ion wit h ot her com ponent s, and so on. The hierarchy browser t o t he left of t he figure serves t o organize t he design int o logical groupings corresponding t o organizat ions and assem blies. I n addit ion, t he scenario m odels and recorded run- t hroughs are organized in t he hierarchy browser. The hierarchy browser rem ains visible t hroughout t he ent ire developm ent cycle in all t ool m odules. Each m odule of t he I DE will show t he hierarchy cont aining t he art ifact s from t he previous m odule plus t he addit ional, m odule- specific art ifact s. This allows convergence t o be t racked in bot h direct ions along t he developm ent pat h. Figure 7.5 shows t he scenario m odel view of t he C- BOM m odule. I t is used by t he t eam s t o invest igat e and record t he business dynam ics in t erm s of com ponent m essage flow, condit ional t ransit ions, and visual run- t hroughs. This figure exhibit s a scenario m odel for t he "Execut e one t ransfer" scenario. Each node const it ut es a cont ract bet ween t w o com ponent s. I t records a significant business act ion and how t his business act ion is handled by one of t he com ponent s in t he CRC view. The scenario node docum ent s t he client com ponent of t he act ion and docum ent at ion describing t he act ion. I t also records t he server com ponent t hat fulfills t he act ion as well as t he part icular responsibilit y of t he server

-203-

Convergent Architecture

Chapter 7: The Architectural IDE

com ponent t hat is used. Different pat hs t hrough t he m odel are det erm ined by t he t ransit ion condit ions, as shown by t he t ransit ion " I nsufficient Funds" in t he m odel. The pat hs in t he scenario m odels allow designers t o visually docum ent t he precise cont ract behavior am ong business com ponent s for any or all im port ant business cases. The run- t hrough console shown t o t he right of t he figure is used t o record and st ore any num ber of business- relevant pat hs t hrough t he syst em . Each runt hrough can be st ored and visually replayed at any t im e. These run- t hroughs are used t o generat e det ailed st at e flow t ables ( SFTs) at t he end of t he session. As point ed out in t he CA process, t he SFTs play an im port ant role in subsequent t est ing of t he business syst em . Bot h t he CRC and scenario m odel views have verifiers. Each verifier checks t he int egrit y of t he view according t o t he cont ract - based business m odeling st yle. As point ed out in t he CA process, t his m odeling st yle is based on w idely accept ed concept s of responsibilit y- driven design. At t his level of design, t he m odeling st yle is perennial and independent of a part icular t echnology proj ect ion com ponent . The verifier also can be used t o check t he com plet eness and cleanliness of t he m odel. The result s of t he m odeling sessions are st ored aut om at ically in t he federat ed UML/ XML m odel reposit ory ( discussed lat er) . I n addit ion, consolidat ed HTML/ XML report s and docum ent at ion of t he m odel m ay be generat ed at any t im e from t he C- BOM m odule. Once t he run- t hroughs have been recorded and verified, t hese report s const it ut e t he signoff docum ent s for t he business m odel. At t he end of a business m odeling session, t he developer m ay m ove on t o t he next st age of refinem ent by act ivat ing t he C- RAS m odule via it s respect ive but t on in t he t oolbar. The but t ons for each of t he current ly enabled m odules of t he archit ect ural I DE are shown in t he t oolbar at t he upper right of t he figure.

Th e Fe de r a t e d UM L/ XM L M ode l Re posit or y ( C- M OD ) The Federat ed UML/ XML m odel reposit ory ( see Figure 7.6) aut om at ically int egrat es and coordinat es t he result s from t he various m odules and t heir respect ive view s int o one shared UML/ XML m odel. The reposit ory is a Java im plem ent at ion of t he UML foundat ion m et am odel t hat accom m odat es input and out put via UML- based Java int erfaces as well as XML/ XMI . The UML foundat ion m et am odel is ext ended by UML- com pliant profiles t o support t he m odeling st yles of t he Convergent Archit ect ure. The reposit ory is int egrat ed and synchronized wit h t he reposit ories of ot her t ools em bedded by t he I DE, in part icular wit h Rat ional Rose.

Figur e 7 .6 : Orient at ion of t he C- MOD m odule. The UML reposit ory is invisible t o t he user of t he archit ect ural I DE except in a few well- defined areas as follow s: First , a reposit ory browser let s t he developer view

-204-

Convergent Architecture

Chapter 7: The Architectural IDE

t he precise cont ent s and UML st ruct ure of t he reposit ory at any t im e. The user m ay im port and export t he ent ire m odel or port ions of t he m odel ( m erge) in st andardized UML/ XML form at according t o t he OMG/ UniSys XMI st andard. The im port or export is carried out via a m enu in t he archit ect ural I DE. Second, j ust as ot her I DE m odules, t he C- GEN and C- GEN- I DE bot h access t he reposit ory via Java program m ing int erfaces and script ing int erfaces. This script ing int erface is used, for exam ple, from t he C- GEN m odule during infrast ruct ure generat ion or from t he C- GEN- I DE w hen ext ending and t est ing t he t echnology proj ect ion cart ridge. Third, t he C- MOD also m ay be used from any Java program via it s Java applicat ion program m ing int erface ( API ) . This API is essent ially an exposure of t he UML m et am odel and t he addit ional UML- com pliant ext ensions in Java. I t is docum ent ed in JavaDoc and, aside from being used by t he default m odules of t he archit ect ural I DE, is used by a variet y of ot her m odules and program s for special t asks. I nform at ion and t he availabilit y of such special m odules, known as reusable asset s, are provided on t he Convergent Archit ect ure Web sit e.

The Con ve r ge nt Pa t t e r n Re fin e m e n t Assist a n t ( C- RAS) The C- RAS m odule ( see Figure 7.7) support s prim arily t he convergent UML refinem ent act ivit y of t he analysis- by- design workflow. I t is used by a developer t o furt her refine t he business obj ect m odel from t he C- BOM m odule int o a UML m odel according t o t he current ly enabled m odeling st yle- J2EE/ EJB by default . The t ool assist s t he designer in achieving st yle—conform convergence by channeling t he developm ent according t o docum ent ed refinem ent pat t erns. Figures 7.8 and 7.9 show t he C- RAS m odule and an exam ple of one of t he OPEN refinem ent pat t erns used by t he m odule.

Figur e 7 .7 : Orient at ion of t he C- RAS m odule.

-205-

Convergent Architecture

Figur e 7 .8 : Pat t ern- based refinem ent .

-206-

Chapter 7: The Architectural IDE

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .9 : C- RAS- OPEN pat t ern exam ple. Wit h perm ission ( Henderson- Sellers 1998, Fig. 2.3) Figure 7.8 illust rat es t he refined st at e of t he sam e m odel present ed in t he C- BOM sect ion earlier. Here again, t he hierarchy browser t o t he left of t he figure shows t he convergent com ponent s. When expanded, each com ponent reveals it s current st at e of refinem ent from t he part icular perspect ive of t he C- RAS m odule. Not e t hat t he sam e business obj ect s are st ill visible, but significant det ail has been added. Each part of t he CRC card for each convergent com ponent is now displayed in t he browser. I n t he figure, t he account 's responsibilit y for know ing/ visible, " Know balance," is select ed. To t he right , in t he work area, t he result s of t his select ion can be seen. I n t he w ork area, an overview of t he refined " Know balance" is shown. I t can be seen t hat t his responsibilit y has been m apped t o an at t ribut e and an operat ion, bot h residing in t he default facet of t he account com ponent —an OPR resource com ponent . Not e t hat t he facet is labeled w it h < none> . This m anifest s t hat t he m apping pat t erns t oget her wit h t he J2EE- based m odeling st yle underst and t hat J2EE/ EJB com ponent s current ly only provide single int erfaces. Facet s are a com ponent feat ure st em m ing from t he CORBA com ponent m et am odel. They exist t o support com ponent s wit h m ult iple int erfaces, provided it is allowed by t he

-207-

Convergent Architecture

Chapter 7: The Architectural IDE

m odeling st yle ( w it h it s corresponding t echnology proj ect ion) . I n t his case, t he default J2EE/ EBB proj ect ion is used. I t is im port ant t o not e t hat int elligent sensit ivit y t oward t he part icular deploym ent infrast ruct ure begins here. I f t he designer w as allowed t o m odel m ult iple int erfaces, t hat is, facet s, t hen t he m odel could not be m apped cleanly ( neit her aut om at ically nor by hand) t o t he int ended J2EE/ EJB infrast ruct ures. By adding t his const ruct ive foresight , t he developer is assist ed in creat ing a m odel t hat can be used t o effect ively drive all dow nst ream st ages of developm ent , m any of t hem aut om at ically. The t abs at t he t op of t he work area show how a developer refines a select ed responsibilit y. Each t ab present s t he pat hs available for refinem ent according t o t he refinem ent pat t erns. One of t hese pat t erns is show n in Figure 7.9. This is t he pat t ern for UML refinem ent of public/ visible responsibilit ies from CRC cards in t he business obj ect m odel. The pat t ern in t he figure indicat es t hat a public/ visible responsibilit y for know ing, which corresponds t o t he current ly select ed responsibilit y, m ay be refined t o visible operat ions or propert ies ( at t ribut es) of a com ponent . When proceeding fart her down in t he pat t ern, it can be seen how t hese operat ions and at t ribut es m ay be furt her refined. These refinem ent opt ions are m ade available t o t he developer by t he C- RAS for t he select ed responsibilit y. The developer t hen uses t he t abs t o creat e t he required set of operat ions and at t ribut es and t o configure t heir det ails. Such det ails are, for exam ple, t he at t ribut e's nam e, t he operat ion's param et er list , or it s precondit ions and post condit ions. The lower part of t he workspace provides direct ions and explanat ions t o t he developer concerning each t ype of refinem ent according t o t he pat t erns. As in all m odeling m odules, a verifier helps t he developer see t he int egrit y and st at us of refinem ent for each ent it y in t he m odel. The ent it ies m arked by a green check have been sufficient ly refined t o sat isfy t he pat t ern. A red exclam at ion point m eans t hat refinem ent is st ill incom plet e for t hat ent it y. The developer does not have t o refine all ent it ies before proceeding t o t he next m odule; he or she can com e back lat er and com plet e t he m odel in increm ent s, each t im e rem oving a new set of red exclam at ion point s. This process can begin w it h changes at t he C- BOM level as well, of course. At t he end of each refinem ent session, t he developer m oves on t o t he next st age of refinem ent by act ivat ing t he C- REF/ Rose t ool via t he Rose but t on. This but t on is shown at t he upper right of t he figure in t he t oolbar of t he archit ect ural I DE.

Th e Con ve r ge n t UM L Re fin em e n t Assist a nt ( C- REF) The C- REF m odule ( see Figure 7.10) em beds Rat ional Rose and support s t he lat er phases of t he analysis- by- design workflow and all m odel- driven act ivit ies downst ream from t he analysis- by- design workflow. I t assist s t he developer during UML refinem ent of all convergent com ponent s according t o t he current ly enabled m odeling st yle—J2EE/ EJB by default . I t is also used t o configure and m anage m odel- driven act ivit ies ( generat e, build, t est , deploy) from t he perspect ive of a proj ect t eam as well as from t he perspect ive of t he special configurat ion requirem ent s of a part icular inst allat ion.

-208-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .1 0 : Orient at ion of t he C- REF m odule. Figures 7.11 t hrough 7.14 exhibit several aspect s of UML m odel refinem ent . This begins wit h a diagram of a com plet ed business com ponent m odel in UML, followed by a look at how det ails of t he m odeling st yle are m anaged in t his m odule. Figures 7.13 and 7.14 are corresponding I nt ernet accessor and process m odels in UML.

Figur e 7 .1 1 : Convergent J2EE/ UML refinem ent .

-209-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .1 2 : Det ails of t he default J2EE/ EJB m odeling st yle.

-210-

Chapter 7: The Architectural IDE

AM FL Y

Convergent Architecture

TE

Figur e 7 .1 3 : The m ult ichannel assessor design.

-211-

Team-Fly®

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .1 4 : The process design. The figures show n t hus far in t his chapt er originat e from a developm ent t ut orial called iBank. The screenshot s used from here on out in t his chapt er are t aken from a com plet ely different business case, a syst em for t rip planning and flight booking. The t rip- planning case bears w it ness t o t he universal applicabilit y of t he convergent com ponent s and t he archit ect ural I DE across business organizat ions and dom ains and allows m e t o show som e m ore com plex aspect s of t he archit ect ural I DE. More ext ensive t ut orial exam ples are also available on t he Convergent Archit ect ure Web sit e. Figure 7.11 exhibit s t he t rip- planning m odel in t he C- REF/ Rose m odule. I n t he CREF m odule, Rat ional Rose is em bedded as a com ponent wit hin t he archit ect ural I DE. The C- REF m odule ( a Java syst em ) adds num erous feat ures t o assist t he archit ect ure- conform use of Rose. I n ot her w ords, Rose is configured and act ively " driven" by t he C- REF m odule t o support t he UML- relat ed st ages of developm ent according t o t he archit ect ural st yle. The int elligent feedback and aut om at ion provided by t he C- REF ensure a m ore effect ive, higher- qualit y approach bot h at t he individual developer level and at t he cross- proj ect or corporat e archit ect ure level. Here again, t he hierarchy browser in t he C- REF displays t he convergent com ponent s t hat w ere creat ed and refined in t he C- BOM and C- RAS m odules. They rem ain visible so t hat t heir evolut ion can be t racked in bot h direct ions along t he developm ent pat h. The UML- level adornm ent s of t he com ponent s are now also visible. Many of t hese adornm ent s were creat ed aut om at ically by t he C- RAS or via

-212-

Convergent Architecture

Chapter 7: The Architectural IDE

t he wizards and m odeling assist ant s in t he C- REF. I n addit ion t o t he elem ent s im port ed from t he C- RAS st ep, t he developer can add new convergent com ponent s direct ly in t he C- REF. Such newly added com ponent s are subsum ed aut om at ically t o t he C- RAS and C- BOM levels via t he com m on reposit ory. They can t hen be com plet ely docum ent ed at t he C- RAS and C- BOM levels lat er. This m eans t hat t he developer can begin designing in t he C- REF/ Rose if appropriat e for t he t ask at hand. Beginning at t he UML level is oft en reasonable w hen developing assem blies of ut ilit y com ponent s, assem blies consist ing m ost ly of accessors, or for ad hoc t est ing and evaluat ion of alt ernat ives in early invest igat ion st ages of t he proj ect . The workspace in t he figure shows t hat t he developer has added an EJB Dependent Value in t he UML m odel t o opt im ize t he t ransport of t he com ponent 's st at e in a dist ribut ed environm ent . As part of t he J2EE/ EJB specificat ion, Dependent Values are clearly addressed by t he m odeling st yle and t he corresponding t echnology proj ect ions. This m eans t hat inst ead of creat ing arbit rary UML const ellat ions, such aspect s can be creat ed or m odified in t he UML m odel according t o t he m odeling st yle and t hen verified for a configured t echnology proj ect ion—a prerequisit e for t he ext ensive generat ion of a high- value infrast ruct ure. How t he C- REF support s each of t hese st yle- based enhancem ent s is exem plified by t he Figure 7.12. I n t his figure, t he convergent resource com ponent " Flight " from Figure 7.11 is now being det ailed and verified. The dialog t o t he right is t he Rose specificat ion dialog for t he flight com ponent . I n t he dialog, t he Rose UML t abs have been com plem ent ed by a num ber of t abs t o support t he archit ect ural st yle. The cont ent of one such propert ies t ab, t he ArcSt ylerEJB1.1 t ab, is select ed and fully visible in t he figure. This t ab perm it s t he developer t o opt im ize t he EJB configurat ion of t he com ponent . The propert ies in t he t ab are st andard EJB1.1 propert ies. I n addit ion, propert ies in t he t ab affect t he generat ion of cert ain EJB conform feat ures. The gray propert ies are t he default s provided by t he t echnology proj ect ion com ponent ( t hat is, t he m odeling st yle in conj unct ion wit h t he configured t echnology proj ect ion cart ridge) . These default s are by no m eans arbit rary. They have been select ed by expert s based on ext ensive t est ing and experience t o be t he best default com binat ion in t his part icular const ellat ion. The developer m ay override t hese default s. This is carried out wit hin t he t olerances of t he m odeling st yle, of course. Knowing t hese t olerances is good because t hey represent t he real- world t olerances of t he J2EE/ EJB infrast ruct ure. To override a propert y while rem aining st yle- conform , t he propert y in t he dialog is select ed t o display t he opt ions available. The black- colored propert ies in t he figure are ones where t he default set t ing has been overridden by t he developer. For exam ple, t he developer has m odified t he propert y det erm ining t he generat ion of default fact ory operat ions for t he com ponent . I n t his case, t he select ed set t ing inst ruct s t he cart ridge t o generat e fact ory operat ions t hat expose all at t ribut es of t he com ponent as form al param et ers. The ot her t abs visible in t he t op of t he dialog cont ain im port ant groupings of propert ies for such aspect s as t uning t he obj ect - t o- relat ional m apping of t he com ponent or t he cont ainer- m anaged persist ence ( CMP) engine of a part icular J2EE/ EJB infrast ruct ure. I n addit ion, t abs addressing unique feat ures of a part icular J2EE/ EJB infrast ruct ure appear wit h each newly inst alled t echnology proj ect ion cart ridge. For exam ple, Figure 7.12 shows t he t abs for t he Borland Applicat ion Server ( BAS) as well as t he t abs for t he BEA Web Logic Server ( WLS) . These separat e propert y groups, as m anifest ed by t ab sheet s in Rose, ensure a clean separat ion of concerns. Each grouping m ay change independent ly from t he ot hers. However, t his does not m ean t hat t he t echnology proj ect ion cart ridge is

-213-

Convergent Architecture

Chapter 7: The Architectural IDE

oblivious t o int eract ions bet ween t he groupings. I n fact , one of t he prim ary advant ages of having a w ell- defined m odeling st yle and int elligent t echnology proj ect ion support in t he I DE is t he fact t hat such int eract ions can be checked and opt im ized. This is no sm all t ask when one considers t he num ber of possible int eract ions bet ween t he various possible t uning param et ers. The t echnology proj ect ion cart ridge can globally opt im ize t he int eract ions bet ween m odel propert ies when code generat ion occurs. During code generat ion, t he current ly enabled t echnology proj ect ion cart ridge int erpret s each and every one of t he propert ies and generat es code and an infrast ruct ure t uned t o t he part icular EJB/ J2EE infrast ruct ure and it s environm ent . This is in st ark cont rast t o generat ors t hat produce lowest - com m on- denom inat or code. Such lowest - com m ondenom inat or code is essent ially useless in real- world sit uat ions. Generat ing opt im ized code m eans not only t hat each param et er in t he m odeling st yle m ust be m apped int elligent ly by t he cart ridge, but also t hat t he int eract ions bet w een any num ber of param et ers can be considered in order t o generat e a well- rounded, globally opt im ized im plem ent at ion for t he part icular infrast ruct ure at hand. Such global int eract ions of propert ies and st ruct ures in t he UML m odel m ay affect m yriad aspect s of code generat ion, as clearly shown in t he bonus chapt er on t he Web sit e. This is known as fan- out coordinat ion and fan- out opt im izat ion because a single propert y change m ay affect m any part s of an infrast ruct ure. Proper coordinat ion of t he fan- out , t he prerequisit e t o global opt im izat ion of t he fan- out , precludes t he use of so- called round- t rip engineering ( RTE) as it is current ly defined by t he t ool indust ry. I n addit ion, m odels produced via RTE of arbit rary code would m ake it im possible t o m aint ain and aut om at e a clean m odeling st yle across designs, proj ect s, and im plem ent at ions. Anot her advant age of t he well- form ed, clean m odeling st yle is shown in t he second dialog of Figure 7.12, t he m odel- validat ion dialog. This dialog is used t o aut om at ically verify archit ect ural int egrit y according t o t he archit ect ural st yle. I t assert s whet her t he current m odel or t he select ed m odel elem ent conform s t o t he requirem ent s of t he current ly configured t echnology proj ect ion com ponent . The dialog shows t hat various levels of conform it y can be checked at any given inst ant . I n addit ion t o st ruct ural conform it y and com plet eness of t he m odel, t he " EJB cart ridge const raint s" allow t he developer t o verify t he feasibilit y of any m odeling decisions wit h respect t o t he available runt im e infrast ruct ure. I n t his part icular case, t he Borland Applicat ion Server ( BAS) version 4.5 is current ly configured and will be used t o check t he t echnical feasibilit y of t he m odel. I f t he developer has used m odeling const ruct s t hat cannot be reasonably ( realist ically) m apped t o t he given BAS version, t hen a warning or error dialog will display an explanat ion. Warnings dialogs signal possible design conflict s or dubious const ellat ions, whereas error dialogs inform t he developer of why an effect ive t echnology proj ect ion of t he given UML const ruct ion is im possible in t he current configurat ion. An exam ple of an error sit uat ion would be t he use of com ponent inherit ance in t he UML m odel in conj unct ion wit h one of t he m any J2EE/ EJB cont ainers t hat do not support com ponent inherit ance. [ 1] Via t he m odel validat ion dialog, t he designer receives j ust - in- t im e feedback regarding t he problem . This is com parable wit h t he j ust - int im e feedback provided t o a program m er by t radit ional com pilers, now at a m uch higher level of design expression—t he UML level. Figure 7.13 shows part of an accessor design in t he C- REF m odule. This part icular accessor diagram shows a default edit or accessor wit h it s default represent ers for t he sam e flight com ponent shown in t he preceding figures. The default accessor was generat ed aut om at ically by select ing t he flight com ponent and t hen select ing t he desired t ype of default accessor. Based on t he inform at ion in t he Flight convergent com ponent , t he accessor was derived aut om at ically according t o t he

-214-

Convergent Architecture

Chapter 7: The Architectural IDE

m odeling st yle. The developer can use t he default accessors t o t hen creat e cust om accessors or can use t he default accessor as is. The dialog in t he lower part of t he figure exhibit s one of several accessor configurat ion dialogs. I t shows t he int eract ion at t ribut es and event - handling propert ies as creat ed wit h t he default edit or accessor. The accessor diagram it self is a UML- com pliant act ivit y diagram . The diagram in t he figure exhibit s t w o represent ers, t wo em bedded ( reused) accessors, and t he event - driven t ransit ions bet ween t hese elem ent s. Based on t his inform at ion, t he t echnology proj ect ion cart ridge for J2EE accessors generat es t he servlet , JSP, and, in t his part icular configurat ion, t he HTML infrast ruct ure t o access t he flight com ponent . The hierarchy browser t o t he left show s t hat considerable det ail regarding accessors and represent ers is available t o t he developer and t o ot her m odules of t he I DE as required. The last C- REF figure ( see Figure 7.14) displays a process design diagram for t he sam e t rip- planning syst em . The diagram t o t he right of t he figure indicat es t he st ruct ural relat ionships bet ween t he process convergent com ponent , BookingProcess, and ot her OPR convergent com ponent s in t he m odel. A process flow diagram is visible in t he cent er of t he figure. Sim ilar t o accessor diagram s, process flow diagram s are UML- com pliant act ivit y diagram s t hat have been enhanced by t he archit ect ural I DE t o support t he overall archit ect ural st yle. The sm all Process Com ponent dialog t o t he upper left of t he figure show s one exam ple of such an enhancem ent . The dialog illust rat es how t he m odeling st yle coordinat es t he creat ion and assignm ent of process roles t o process t ypes in t he m odel. This is j ust one of several process- m odeling dialogs t hat m ay be used by t he developer t o refine t he process ( also known as workflow) aspect s of t he OPR m odel based on t he concept s described in Chapt er 4. Once t he m odel has been validat ed, opt im ized code can be generat ed wit hout leaving t he C- REF m odule. To t his effect , t he convergent t ranslat ive generat or ( CGEN) m odule is act ivat ed, as described in t he next sect ion. [ 1]

Com ponent inherit ance is not defined by t he current J2EE/ EJB st andard; t hus any support for com ponent inherit ance const it ut es a unique, added- value feat ure of t he part icular applicat ion ser ver. The ext ent and usabilit y of t hese feat ures differ great ly bet ween applicat ion servers.

Th e Con ve r ge n t Tr a n sla t ive Ge n e r a t or ( C- GEN ) The C- GEN m odule ( Figure 7.15) is anot her self- cont ained com ponent in t he archit ect ural I DE. I t is norm ally act ivat ed direct ly from t he C- REF m odule so t hat t he developer can perform rapid increm ent s of UML m odeling and subsequent infrast ruct ure generat ion. However, t he C- GEN also can be called as an independent Java com ponent via a Java API or from t he com m and line.

Figur e 7 .1 5 : Orient at ion of t he C- GEN/ C- GEN- I DE m odule.

-215-

Convergent Architecture

Chapter 7: The Architectural IDE

The basic concept behind t ranslat ive generat ion as em ployed by t he C- GEN also has been referred t o as a t hird- generat ion design for code generat ors ( Mellor 1999) . The C- GEN im plem ent s t ranslat ive generat ion by reading t he C- REF/ UML m odel from one source, t he m odel reposit ory, and reading t he t ranslat ion inform at ion on one or m ore infrast ruct ures from anot her source, t he t echnology proj ect ion cart ridges. This const ellat ion allows t he developer t o plug in various t ranslat ion aspect s in t he form of cart ridges. Once t he cart ridges are configured, generat ion can begin. Figure 7.16 illust rat es how t echnology proj ect ion cart ridges are configured int o t he archit ect ural I DE and st ored as part of t he proj ect configurat ion. The figure shows t he proj ect configurat ion dialog t hat is used by t he ent ire archit ect ural I DE t o edit and st ore proj ect inform at ion. I n t his part icular screenshot , t he t ab t o configure t he C- GEN has been select ed, and a subt ab, Proj ect ions, has been act ivat ed t o configure t he t echnology proj ect ion aspect s. I n t his part icular proj ect , t wo cart ridges have been configured, one for t he Borland Applicat ion Server version 4.5 ( BAS45) and one for J2EE/ JSP accessors. The BAS45 cart ridge is select ed in t he figure, which m eans t hat it s cart ridge det ails are displayed for configurat ion in t he cent er of t he dialog. Som e of t hese det ails are set aut om at ically on inst allat ion of t he archit ect ural I DE because t hey can be derived from t he local environm ent . Ot hers are init ialized t o cart ridge- specific default s. They can be m odified t o adapt t o changes in t he environm ent . For exam ple, t he param et ers affect ing t he generat ion, build, and execut ion of t he t est environm ent can be m odified. I n t he case of t he BAS45 cart ridge shown in t his dialog, t est client s require a port num ber for t he Visibroker Sm art Agent . Since t his port num ber m ay need t o be changed, for inst ance, t o enable parallel t est ing by several developers, t he default port m ay be m odified in t he configurat ion dialog.

-216-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .1 6 : Configuring cart ridges and proj ect s. Figure 7.17 shows t he graphical int erface t o t he C- GEN m odule. I n t he C- GEN m odule, t he convergent com ponent s are visible in t he hierarchy browser t o t he left , as always. The figure shows t hat t he t rip- planning proj ect from earlier is now ready t o be generat ed using t he configured t echnology proj ect ions. The t abs shown at t he t op of t he work area are used t o select t he inform at ion and out put consoles for each of t he configured t echnology proj ect ion cart ridges, respect ively. The cart ridges cont ain inform at ion regarding grouping and dependencies wit h ot her cart ridges. This inform at ion is used by t he C- GEN m odule t o let t he developer select various valid subset s for generat ion. For exam ple, t he developer can select ively generat e t he J2EE/ JSP accessor aspect s of t he m odel or of a m odel elem ent wit hout having t o generat e it s ent ire EJB infrast ruct ure each t im e.

-217-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .1 7 : Generat ing infrast ruct ure and environm ent . The lower port ion of t he work area in t he figure shows t he C- GEN out put console. The cart ridge writ es progress and log inform at ion, in t his case from t he J2EE/ JSP accessors, t o t his console. I n t his part icular case, log inform at ion for t he generat ed Tom cat servlet - engine configurat ion, JBuilder support , and ANT build support is visible. What if t he com ponent developer want s t o change or ext end t he behavior of t he cart ridge for a part icular t est environm ent ? Or t he chief archit ect and archit ect ural I DE specialist want t o change t he behavior of t he cart ridge used in every proj ect across t he ent ire I T organizat ion? I n such cases, t hey use t he C- GEN- I DE m odule described in t he next sect ion. The Conve r ge nt Ge n e r a t or I D E ( C- GEN - I D E) The C- GEN- I DE m odule of t he archit ect ural I DE is used t o edit , t est , and debug t echnology proj ect ion cart ridges. Each cart ridge cont ains t em plat es, JPyt hon script s, and ot her art ifact s t hat are organized according t o t he so- called cart ridge archit ect ure. I t is im port ant t o not e t hat t echnology proj ect ion cart ridges t hem selves are ext ensive program s. They are referred t o as m et aprogram s because t hey generat e ot her program s and infrast ruct ures via t he C- GEN m odule. As such, it can be seen as a m et aprogram m ing I DE t hat provides t he developer wit h a m odern environm ent com parable wit h fam iliar Java I DEs. I n fact , m uch of t he archit ect ural I DE it self is generat ed based on UML m odels and t echnology proj ect ion cart ridges. Thus, it is im port ant t hat t he cart ridge infrast ruct ure it self be well designed. The cart ridge archit ect ure defines how cart ridges are st ruct ured in order t o guarant ee all t he t hings we expect from well- designed syst em s: t he proper use of obj ect - orient ed design, localit y of cart ridge code, reuse of cart ridge code, m odular

-218-

Convergent Architecture

ƒ

ƒ ƒ

ƒ

Chapter 7: The Architectural IDE

com posit ion of t he cart ridge, m odular ext ension point s, evolut ionary updat es t o cart ridges, and so fort h. However, only t he archit ect ural I DE specialist s and, in rare cases, t he developm ent t oolsm it h ( see Chapt er 5) m ust underst and t he working feat ures of t he cart ridge archit ect ure. I t is used by t hese workers t o ext end and develop cart ridges according t o t he cart ridge archit ect ure. Figure 7.18 is a t ypical screenshot of t he C- GEN- I DE in act ion. This figure shows t hat t he C- GEN- I DE is a m odule in t he archit ect ural I DE. Just like all t he ot her m odules, once act ivat ed, it ( dynam ically) adds it self at t he appropriat e point in t he archit ect ural I DE. I t t hen conform s in look and feel t o all ot her m odules described t hus far because it shares t heir com m on infrast ruct ure. The hierarchy brow ser t o t he left displays t he current proj ect , as always, at t he sam e level of abst ract ion t hat appears in t he C- GEN it self. By default , t he w ork area is divided int o quadrant s as follows: The quadrant at t he upper left cont ains t he cont ext - sensit ive source edit or for t he t em plat e source, JPyt hon source, or ot her art ifact s of t he current ly select ed cart ridge. The files appear as t abs at t he bot t om of t he edit ing area, as shown in t he figure. Many of t hese files will be loaded dynam ically by t he I DE as a result of t est ing or browsing t asks. When a code area is m arked in t he source edit or, t he corresponding areas are highlight ed in t he int erm ediat e code viewer in t he quadrant t o it s right : t he JPyt hon code viewer. The JPyt hon code viewer t o t he upper right shows t he t ranslat ed result of t he code in t he source edit or. This is t he int erm ediat e JPyt hon code t hat is used t o generat e t he act ual infrast ruct ure. [ 2] The quadrant t o t he lower left cont ains bot h t he debugging t oolbar and t he out put / log console. Debugging proceeds j ust like in any program m ing I DE. Break point s can be set , and t hen t he generat or can be st art ed t o run t o t he break point , using w at ch point s along t he w ay as required. Ot her norm al debugger feat ures such as single- st ep, st ep- over, st ep- int o, and so on. are also available. The console area displays t he cart ridge out put and log inform at ion j ust as in t he C- GEN console. I n addit ion, if select ed, t he console shows t he end result of each generat ion st ep—t he Java code, XML files, I DE proj ect files, deploym ent descript ors, build script s, t est script s, and so on. The quadrant at t he lower right is t he ext ensible evaluat ion panel. I t is com parable w it h a flexible regist er list or st ack viewer in a source- code debugger. I n addit ion t o several st andard wat ch expressions, it m ay be ext ended by t he developer using arbit rary JPyt hon expressions t o wat ch any ot her aspect of t he generat or or cart ridge.

-219-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .1 8 : Using t he generat or I DE. The m et a- program m ing environm ent . [ 2]

There are several very good reasons for generat ing int erm ediat e JPyt hon code from all t he int eract ing part s of t he cart ridge, for exam ple, t o im prove reuse, debugging, and generat ion perform ance.

Th e I m ple m e n t , D e ploy, a n d Te st En vir on m e n t ( C- I X) The im plem ent , deploy, and t est environm ent m odule ( C- I X) ( see Figure 7.19) leverages a high- end program m ing I DE ( for exam ple, Java or C+ + I DE) and deploym ent and t est t ools. Sim ilar t o t he em bedded UML t ool in t he C- REF m odule ( Rat ional Rose) , t he C- I X encapsulat es, int egrat es, and drives t hese t ools t o assist t he developer along t he crit ical developm ent pat h. Like t he C- REF, t he C- I X achieves t his by enhancing and com plem ent ing t he Java I DE ( JBuilder in t his case) , t ools, and infrast ruct ure w it h t w o t hings. First , it seam lessly int egrat es t he C- I X com ponent s wit h t he rest of t he archit ect ural I DE; t his int egrat ion applies t o t he m odules concept ually before, aft er, above, and below t he Java I DE and t he ot her t ools coordinat ed by t he C- I X. Second, it adds archit ect ural- st yle- specific feat ures such as t he m odeling st yle and m odel- driven t echnology support for t he code, t est , build, and deploym ent aspect s of t he syst em .

-220-

Convergent Architecture

Chapter 7: The Architectural IDE

TE

AM FL Y

Figur e 7 .1 9 : Orient at ion of t he C- I X m odule. The following t hree figures are used t o exhibit several of t he cent ral feat ures of t he C- I X m odule. Figure 7.20 displays t he generat ed code and t est infrast ruct ure as used t o deploy and t est t he convergent com ponent s in t he cont ext of t he Java I DE. Figure 7.21 shows t he generat ed accessors as t hey are displayed for t est ing or refinem ent in eit her t he Java I DE or, equivalent ly, in a Web- design t ool such as Dream Weaver or Ult raDev. Figure 7.21 illust rat es t he convergent com ponent s as deployed in t he operat ional environm ent or t he assem bly t est environm ent .

Figur e 7 .2 0 : I m plem ent , deploy, and t est com ponent s.

-221-

Team-Fly®

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .2 1 : I m plem ent , deploy, and t est accessors. Figure 7.20 shows t he t rip- planning proj ect in JBuilder. The JBuilder proj ect files and build environm ent for t he t rip- planning proj ect were generat ed aut om at ically from t he C- REF/ UML m odel shown in previous sect ions. The t wo brow sers at t he left of t he figure indicat e t hat convergence has st ill been preserved at t he sourcecode level: The flight com ponent and ot her OPRs from t he business m odel are clearly visible in t he browsers. As always, t he brow ser shows t he accom panying art ifact s relevant t o t he com ponent in t his life- cycle st age and t o t his m odule of t he archit ect ural I DE. I n t he w ork area, we see one of t he generat ed Java files, Flight Bean.j ava, displayed in t he code edit or. I n t he edit or, t he generat ed com m ent s and prot ect ed areas are colored green. The long num ber at t he bot t om of each prot ect ed area com prises so- called check- sum inform at ion and ot her inform at ion t hat is used by t he C- GEN t o int elligent ly m anage t he prot ect ed area across repeat ed generat ion runs. I n t he upper prot ect ed area, t he developer has added a single line of business logic t o check whet her t he sum of booked seat s plus t he num ber of request ed seat s surpasses t he num ber of available seat s. I n t he t ool bar, t he developer has act ivat ed t he Run Proj ect m enu. The m enu present s t he unit t est proj ect s for bot h client and server aspect s of t he assem bly. This infrast ruct ure, including t he JBuilder proj ect configurat ion required t o build and run t he t est s, also was generat ed from t he C- REF/ UML m odel. The developer uses t his m enu t o build and t est t he assem bly or part s of t he assem bly. Rem em ber t hat t he packaging of t he convergent com ponent s int o t est able unit s also was m odeled in t he C- REF/ UML m odule as described in Chapt er 6. This enables t he generat ion of a properly part it ioned t est infrast ruct ure. The result of act ivat ing t he generat ed m enu it em "EJB t est server" is shown at t he bot t om of t he figure. When t he m enu it em is act ivat ed, t he proj ect dependencies are checked aut om at ically, and t he com ponent s are built . I f com pilat ion is successful, t he t est proceeds t o aut om at ically package t he com ponent s t oget her wit h t he ot her generat ed art ifact s required for deploym ent —t he J2EE/ EJB deploym ent descript ors, for exam ple. Then t he applicat ion server is act ivat ed, and

-222-

Convergent Architecture

Chapter 7: The Architectural IDE

t he package is aut om at ically deployed int o t he applicat ion server. I n JBuilder, t his all happens wit hin t he Java- I DE environm ent . The out put at t he bot t om of t he figure shows t he act ive Borland Applicat ion Server as well as t he act ive Tom cat servlet engine. Once t he t est server is loaded, t he unit t est client s and accessors m ay be built and st art ed aut om at ically in a sim ilar fashion. Figure 7.21 shows an exam ple of such accessors in t he t rip- planning proj ect . These accessors were generat ed from t he C- REF/ UML m odel show n in Figure 7.13. I n t his figure, t he JBuilder proj ect for t he accessors package has been select ed in t he browser. This unit was given t he nam e WebApplicat ion in t he C- REF/ UML m odel. The browser shows t he accessors and t heir corresponding represent ers j ust as t hey appeared in t he corresponding C- REF/ UML browser ( t he left side of Figure 7.13) . These art ifact s, including t he JBuilder proj ect and ot her infrast ruct ures required t o build, deploy, and t est t he accessors, were all generat ed direct ly from t he C- REF/ UML m odel. I n t he figure, one of t he represent ers, Flight _Edit orDR, has been select ed and appears in t he JBuilder edit or t o t he right . This is t he default represent er ( indicat ed by t he suffix DR) . [ 3] This m odel is shown on right side of Figure 7.13. For t he flight - edit or represent er, t he HTML/ JSP view has been select ed by t he JBuilder edit or. This view allows t he developer t o visually edit t he HTML/ JSP represent at ion in JBuilder. However, t he graphic edit ing of represent ers norm ally is done by t he com put er ergonom ics and GUI expert ( see Chapt er 5) . As explained in t he developm ent m odel, t his expert uses high- end Web page design t ools such as Dream Weaver or Ult raDev t o polish t he Web page layout . Such edit ing also occurs using exact ly t he sam e generat ed represent ers. Bot h Java- I DE and Web design t ools are com plet ely com plem ent ary com ponent s of t he C- I X m odule. JBuilder is used by t he accessor developer t o m anipulat e, build, and t est t he accessor int ernals, whereas t he Web design t ool is used by t he GUI expert t o m anipulat e t he HTML/ JSP represent ers of t he accessor—t he opt im al separat ion of concerns. Bot h t he accessor developer and GUI expert operat e in t heir area of expert ise wit h t heir high- end t ools, and t he result s are com plet ely harm onious. The represent er files saved by t he Web design t ool can be updat ed im m ediat ely in JBuilder and can be t est ed im m ediat ely wit h t he rest of t he assem bly. The st eps t aken t o build, t est , and deploy t he accessors are ident ical t o t he procedure described previously ( see Figure 7.20) for t he server- side aspect s of t he assem bly: The developer uses t he preconfigured Run Proj ect m enu in t he JBuilder t oolbar, and t est ing proceeds via t he t est client s and accessors. I n t his part icular exam ple, t he Web accessors m ay be st art ed wit hin t he JBuilder environm ent or from a st andard Web browser out side t he environm ent , depending on t he level of inst rum ent at ion required. The st andard Web browser is used t o t est t he look and feel of t he applicat ion from t he end- user's perspect ive. This brings us t o Figure 7.22, which shows one view of t he t rip- planning assem bly as deployed in t he operat ional environm ent . As described in t he CA process ( see Chapt er 6) , t his environm ent is also used t o t est t he assem bly before release.

-223-

Convergent Architecture

Chapter 7: The Architectural IDE

Figur e 7 .2 2 : The operat ional deploym ent and assem bly t est . This figure shows an applicat ion server console. I n t his part icular case, it is t he console for t he Borland Applicat ion Server; however, it could j ust as well be t he console for t he BEA WebLogic Server, t he I BM WebSphere Server, or ot her applicat ion servers. The view select ed in t his figure displays t he deployed assem bly. I t provides clear evidence t hat convergence has been achieved for t he t ripplanning syst em . The convergent com ponent s are visible in t he browser t o t he left of t he figure: t he business com ponent s in t he EJB cont ainer branch and t he accessors in t he Web cont ainer branch. I n t his part icular screenshot , t he EJB references view of t he business com ponent s has been select ed. This shows t he convergent com ponent s and t heir reference in t he deployed J2EE/ EJB environm ent . Not e t hat t he OPR business com ponent s—flight , reservat ion, t rip—are st ill clearly visible in t he operat ional m onit oring environm ent . This aspect of t he C- I X m odule perm it s t he assem bly t o be m anipulat ed and m onit ored in t he operat ional infrast ruct ure during t he various phases of it s life cycle: Assem bly t est s, t ransit ion act ivit ies, and day- t o- day and operat ional act ivit ies are all carried out in t his environm ent . This level of aut om at ion m akes operat ional t est s possible in early it erat ions of t he developm ent proj ect . For exam ple, developers can int egrat e, deploy, and t est t he assem bly in t his

-224-

Convergent Architecture

Chapter 7: The Architectural IDE

operat ional const ellat ion direct ly from JBuilder. This allows part s of t he syst em t o be inst rum ent ed and t est ed from t he Java- I DE environm ent by one com ponent developer while using ot her part s of t he assem bly t hat have been deployed by ot her com ponent developers. I n addit ion, it let s t he assem bly developer, t he t est m anger, and t he deploym ent m anager verify t he deploym ent and m onit oring capabilit ies of t he operat ional environm ent early on in t he proj ect . These diverse deploym ent and t est ing needs, each corresponding t o different st ages of t he crit ical developm ent workflow, are int elligent ly support ed by t he C- I X m odule as a part of t he overall archit ect ural I DE. [ 3]

I t is im port ant t o not e t hat t his const it ut es generat ed code t hat was aut om at ically derived from a previously generat ed m odel, which was derived in an assist ed m anner from a business m odel. Not j ust one aut om at ion st ep, but a whole series of increasingly powerful aut om at ion st eps are m ade possible by t he archit ect ural st yle.

Su m m a r y This chapt er provided concret e illust rat ions and descript ions of t he archit ect ural I DE and it s im port ant role as a part of t he Convergent Archit ect ure. I n part icular, it addressed t he m echanism s of t he t hird and fourt h feat ures in an I T- archit ect ural st yle described in Chapt er 1 ( refer t o Figure 1.1) . These feat ures are t he fullcoverage t ool suit e and t he form al t echnology proj ect ions, w it h t he focus in t his chapt er being on t he t ools and t heir high- level support of t he developm ent m odel ( see Chapt ers 4, 5, and 6) . I n t he next chapt er t he focal point w ill be shift ed t o t he form al t echnology proj ect ion aspect s. Screenshot s from an act ual archit ect ural I DE, ArcSt yler, were used t o show how m at ure t ools such as Rat ional Rose, JBuilder, and J2EE/ EJB applicat ion servers are int egrat ed and enhanced t o int elligent ly support holist ic archit ect ure in realit yscale proj ect s. Each sect ion present ed one m aj or m odule of t he archit ect ural I DE and illust rat ed how it support s t he developm ent of convergent com ponent s, as described in Chapt er 4, t he in t he cont ext of t he I T organizat ion covered in Chapt er 5 using t he CA process defined in Chapt er 6. This began wit h t ool support for t he business m odeling and requirem ent s workflow using t he business obj ect m odeling m odule ( C- BOM) . I t t hen proceeded t hrough t he t hree levels of convergent refinem ent using t he pat t ern- based refinem ent assist ant m odule and t he UML refinem ent m odule for Rat ional Rose ( C- RAS and C- REF) . Finally, support for t he im plem ent at ion cycle, t est workflows, deploym ent , and m onit oring act ivit ies were illust rat ed using t he t ranslat ive generat or and it s m et aprogram m ing m odules ( C- GEN and C- GEN I DE) , followed by t he m odule for t he im plem ent at ion, deploym ent , and t est environm ent ( C- I X) . Up t o t his point , t he t echnology proj ect ion com ponent ( which includes t he guidelines for a m odeling st yle and it s t echnology proj ect ions) has been covered from t he perspect ives of design rat ionale, posit ioning, and st ruct ure as a part of t he archit ect ural st yle, as w ell it s pragm at ic usage in t he archit ect ural I DE. The next chapt er will cover t he last , m ost det ailed perspect ive of t he t echnology proj ect ion com ponent : it s cont ent . I t will provide t he reader w it h det ailed insight int o t his im port ant aspect of t he Convergent Archit ect ure before t he final chapt er will m ove back t o a pragm at ic usage level.

-225-

Convergent Architecture

Chapter 8: Tutorial Example

Ch a pt e r 8 : Tu t or ia l Ex a m ple : Applyin g t h e Con ve r ge n t Ar ch it e ct u r e Ove r vie w This chapt er dem onst rat es t he Convergent Archit ect ure at work. I t consist s of a short , st ep- by- st ep t ut orial t hat applies significant port ions of t he Convergent Archit ect ure ( CA) process in t he cont ext of t he archit ect ural int egrat ed developm ent environm ent ( I DE) . I t dem onst rat es t he t asks required t o develop a convergent J2EE/ EJB sy st em including it s Web accessors ( t he Web applicat ion) using t he ArcSt yler wit h Rat ional Rose, JBuilder/ ANT, and t echnology proj ect ion cart ridges for JSP Web accessors and J2EE/ EJB applicat ion servers. The part icular exam ples used in t his t ut orial dem onst rat e t he use of t he J2EE/ EJB cart ridges for t he BEA Web Logic Server ( WLS) and t he Borland Applicat ion Server ( BAS) . ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

The t ut orial includes t he following st eps, each covered in it s own sect ion: Business m odeling wit h C- BOM Refinem ent int o an init ial UML m odel wit h C- RAS UML m odeling of t he EJB com ponent s wit h C- REF Code generat ion for t he EJB com ponent s w it h C- GEN Building, deploying, and t est ing t he EJB syst em Unified Modeling Language ( UML) m odeling of t he Web accessor com ponent s wit h C- REF Code generat ion for t he Web accessor infrast ruct ure wit h C- GEN Building, deploying, and t est ing t he Web applicat ion Needless t o say, fam iliarit y wit h t he Convergent Archit ect ure is a prerequisit e t o best underst anding t he underlying concept s and advant ages present ed in t his t ut orial.

The J2 EE/ EJB Syst e m : A Con ve r ge n t iBa n k I n t his t ut orial, you will develop t he heart of an I nt ernet banking ( i- bank) syst em : it s account m anagem ent feat ures. I n sum m ary, t he iBa nk consist s of t wo com ponent s: an Account ( resource) com ponent and a Tr a nsfe r ( process) com ponent . The Account com ponent possesses an account num ber and a balance and is capable of m aking t ransact ional w it hdrawals and deposit s. The Tr a nsfe r com ponent can t ransfer funds bet ween a source account and a dest inat ion account . The Account com ponent will be m odeled and im plem ent ed as an EJB ent it y bean using cont ainer- m anaged persist ence. The Tr a nsfe r com ponent w ill be m odeled and im plem ent ed as an EJB st at eful session bean. They will be m odeled int o a single assem bly and deployed in an EJB cont ainer. Then, Web accessors are developed and deployed t o provide a Web- based user int erface for account m anagem ent . This Web front end enables bank personnel t o m anipulat e account s: creat e new account s and edit or delet e account s. Tut or ia l Solut ion A com plet e solut ion for t his exam ple, which includes m odels and all ot her developm ent art ifact s, m ay be found on t he Convergent Archit ect ure Web sit e: www .Convergent Archit ect ure.com . I n som e places, not at ional convent ions are com bined. For exam ple, proj ect .a spr j is used t o designat e a proj ect file for w hich t he nam e is specified by t he user.

-226-

Convergent Architecture

Chapter 8: Tutorial Example

The not at ional convent ion for navigat ing m enus is M e n u → Subm e n u →. . . . Cont ext m enus are accessed by clicking t he right m ouse but t on.

Bu sin e ss M ode lin g w it h C- BOM

ƒ ƒ ƒ ƒ ƒ ƒ

This sect ion covers t he business m odeling and requirem ent s acquisit ion aspect s of t he analysis- by- design work flow ( see Chapt er 6) . The t asks of t his work flow are support ed by t he convergent business obj ect m odeler ( C- BOM) m odule, which assist s in Modeling of business obj ect responsibilit ies and collaborat ions ( st at ic st ruct ure of t he m odel) Modeling of use- case scenarios ( dynam ic behavior of t he m odel) The com plet ed business obj ect m odel includes t he follow ing deliverables: Det ailed dom ain requirem ent s in t he form of a business obj ect m odel Debugged dom ain scenarios in t he form of visual business use- case scenarios, st at e t ransit ion t ables, and run- t hroughs Descript ions regarding specific design t hem es such as m igrat ion, securit y, and host - int egrat ion Model- generat ed HTML docum ent at ion for official business m odel inform at ion and proj ect signoff

SOFTW ARE PREREQUI SI TES The following soft ware prerequisit es m ust be m et for hands- on use of t his t ut orial: ƒ ƒ ƒ ƒ ƒ ƒ

ArcSt yler version 2.6 or higher. Rat ional Rose 2000e or 2001 or 2001 a. JBuilder4 or 5. The use of JBuilder ( or ot her Java I DE) is opt ional because t he ANT ( com m and- line) build environm ent is also explained in t his t ut orial. The advant ages of each w ere explained in Chapt er 7. The ArcSt yler t echnology proj ect ion cart ridge for your t arget J2EE/ EJB cont ainer ( BEA WLS 5.1 and Borland Applicat ion Server 4.5 are used in t he exam ple) . Tom cat servlet engine 3.2 or com pat ible engine ( usually delivered wit h t he applicat ion server) . ArcSt yler iO_ JSP_ a cce ssor s t echnology proj ect ion cart ridge. N OTATI ON AL CON VEN TI ON S Table 8.1 list s t he not at ional convent ions used in t his t ut orial. Ta ble 8 .1 : N ot a t ion a l Conve n t ion s N OTATI ON

D ESCRI PTI ON

iBa nk .a spr j Bold font is used for t he nam es of int erfaces, files, and language keywords. Nam e I t alics are used

-227-

Convergent Architecture

Chapter 8: Tutorial Example

Ta ble 8 .1 : N ot a t ion a l Conve n t ion s N OTATI ON

D ESCRI PTI ON for elem ent s t hat are variable.

Cancel

A sans- serif font is used for t he nam es of GUI widget s, dialogs, m enus and t heir cont ent s, and inform at ion you ent er int o t he GUI field.

ENTER

All capit al let t ers designat es keys on your keyboard.

# de fine A fixed- widt h font is used for code and for inform at ion you ent er at t he com m and line.

ƒ ƒ ƒ ƒ

This sect ion cont ains t he following subsect ions: Set t ing up a proj ect Modeling CRC cards Modeling a business use- case scenario Model verificat ion and docum ent at ion Se t t ing Up a Pr oj e ct St art t he ArcSt yler from t he com m and line or from your syst em m enu. The ArcSt yler com m ander appears on your deskt op. Before you st art m odeling, you need t o set up an ArcSt yler proj ect . An ArcSt yler proj ect file is an XML file w it h t he file ext ension * .a spr j . I t st ores t he proj ect configurat ion inform at ion. I n part icular, it cont ains t ags specifying t he UML/ XML

-228-

Convergent Architecture

Chapter 8: Tutorial Example

reposit ory file m odel.a sr e p and t he Rose m odel m odel.m dl associat ed wit h t he ArcSt yler proj ect . Figure 8.1 shows t he ArcSt yler com m ander aft er creat ing t he iBa nk proj ect and reposit ory. The reposit ory already cont ains a default package, iOCATBa se . This package cont ains som e basic m odel elem ent s, such as elem ent ary dat a t ypes. I t is im port ed aut om at ically in each newly creat ed ArcSt yler reposit ory.

Figur e 8 .1 : The ibank proj ect and reposit ory. M ode lin g CRC Ca r ds You will now design t he st at ic st ruct ure of your business m odel. The business obj ect s of your m odel are represent ed by class responsibilit y collaborat ion ( CRC) cards.

Addin g a Pa ck a ge CRC cards m ust be m odeled wit hin a business m odel package. Therefore, you m ust first add such a package t o your reposit ory. Opt ionally, you m ay ent er t he init ial t ext ual proj ect or scenario descript ion.

Addin g CRC Ca r ds ƒ

I n t his sect ion you design t he CRC cards for t he Account and Tr a nsfe r business obj ect s. Begin w it h t he Account obj ect . Proceed as follows: Add a new resource CRC card, Accou n t , t o t he iBa nk package.

-229-

Convergent Architecture

ƒ

Chapter 8: Tutorial Example

Add t he responsibilit ies list ed in Table 8.2 in t he Re sponsibilit ie s field of t he Account CRC card. Ta ble 8 .2 : Re sponsibilit ie s of t he Account Busine ss Obj e ct

ƒ ƒ

RESPON SI BI LI TY

KI N D

VI SI BI LI TY

Know account num ber

Knowing

Visible

Know balance

Knowing

Visible

Make deposit

Doing

Visible

Make wit hdrawal

Doing

Visible

Model t he Tr a nsfe r obj ect as follows: Add a new process CRC card, Tr a nsfe r , t o t he iBa nk package. I n t he Re sponsibilit ie s and Colla bor a t or s fields of t he CRC card, add t he responsibilit ies and collaborat ors shown in Table 8.3. Ta ble 8 .3 : Re sponsibilit ie s a nd Colla bor a t or s of t he Tr a nsfe r Busine ss Obj e ct RESPON SI BI LI TY

KI N D

V I SI BI LI TY

COLLABORATOR

Know source account

Know ing

Visible

Account

Know dest inat ion account

Know ing

Visible

Account

Know am ount t o be t ransferred

Know ing

Visible

Execut e t ransfer

Doing

Visible

Figure 8.2 shows t he com plet ed CRC cards.

-230-

Chapter 8: Tutorial Example

AM FL Y

Convergent Architecture

Figur e 8 .2 : CRC cards in t he ibank business m odel. M ode ling a Busine ss Use - Ca se Sce na r io

2. 3. ƒ ƒ ƒ ƒ 4.

5. 6. 7. 8.

TE

1.

I n t his sect ion you ent er a business use- case scenario for t he t ransfer process. The t ransfer scenario includes t he follow ing st eps: Check t he balance of t he source account , m ake a wit hdrawal from t he source account , and m ake a deposit on t he dest inat ion account . To m odel t his scenario, do t he following: Add a new business use- case scenario, Ex e cut e one t r a nsfe r , t o t he I Ba nk package. Add t hree scenario st eps. I nsert t ransit ions bet ween t he follow ing st eps: St art point and st ep 1 St ep 1 and st ep 2 St ep 2 and st ep 3 St ep 3 and endpoint Select st ep 1, and choose Tr a nsfe r as Clie nt and Account as Se r ve r from t he respect ive drop- down list s in t hat part of t he w orkspace. Select t he Know ba la nce responsibilit y as t he server's Re sponsibilit y. Add t he following N ot e t o st ep 1: Check if funds are adequat e in source account . Select st ep 2, and set t he sam e client and server, but select M a k e w it hdr a w a l as t he server's Re sponsibilit y. Select st ep 3, set t he sam e client and server, but select M a k e de posit as t he server's Re sponsibilit y. Add t he following N ot e t o st ep 3: W it hdr a w a n d de posit m ust be a n a t om ic t r a nsa ct ion. Figure 8.3 shows st ep 9 of t his business use- case scenario m odeling procedure.

-231-

Team-Fly®

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .3 : Creat ing t he business use- case scenario. To t est t he scenario, you now perform a w alk- t hrough, as described in Chapt er 6, t he CA process. Once t he scenario is verified, t he w alk- t hrough m ay be recorded. Playing back t he recording const it ut es a run- t hrough, as described in Chapt er 6. Figure 8.4 shows t he walk- t hrough recording procedure.

-232-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .4 : Recording a walk- t hrough. You can now play back ( run- t hrough) t he scenario by select ing t he Ex e cut e one t r a n sfe r : de fa u lt ca se walk- t hrough from t he drop- down m enu below t he workspace and clicking t he Run Through but t on. M ode l Ve r ifica t ion a nd D ocum e nt a t ion At t his point , t he st at ic st ruct ure and dynam ic behavior of t he business m odel have been m odeled. To com plet e t he business- m odeling st ep, you can now verify your m odel and generat e an HTML docum ent at ion.

Ve r ifica t ion

ƒ ƒ ƒ ƒ ƒ ƒ

The C- BOM m odule provides a configurable m odel- verificat ion m echanism t o verify t he st ruct ural correct ness and com plet eness of your business m odel. The follow ing aspect s can be validat ed by default : Duplicat e class nam es Responsibilit ies not referenced in a scenario Business obj ect s not referenced in a scenario Cards wit hout responsibilit ies Em pt y business obj ect docum ent at ions Business obj ect s not referenced as collaborat ors

-233-

Convergent Architecture

Chapter 8: Tutorial Example

You can verify single m odel elem ent s or t he ent ire m odel. The verifier not ifies you about t he result s of t he validat ion. I f t he validat ion is not successful, you will get warnings or error m essages. I n t he case of errors, t he m odel m ust be fixed in order t o m aint ain int egrit y as defined by t he archit ect ural st yle.

D ocu m e n t a t ion Now you can generat e t he HTML docum ent at ion from t he m odel. This report is t hen used for design review and signoff.

ƒ ƒ ƒ ƒ

The st ruct ured hypert ext in t his report cont ains t he business- m odel st ruct ure and flows wit h t heir descript ions and requirem ent s broken down as follow s: Model packages and t heir descript ions CRC cards and t heir descript ions, including t he recorded special design t hem es Visual business use- case scenarios Walk- t hroughs and t heir result ing st at e t ransit ion t ables This docum ent can be placed im m ediat ely on t he com pany's int ranet or t he I T organizat ion's int ranet ( see Chapt er 5) for review. At t his point , you have com plet ed t he convergent refinem ent I ( convergent business m odeling) act ivit y of t he analysis- by- design w ork flow. Not e t hat t his procedure has elim inat ed t he high- risk, high- cost st ep of t ranslat ing a dom ain analysis int o a syst em m odel. The init ial iBa nk business m odeling is now com plet e. The result s have been verified and docum ent ed.

Re fin e m e n t w it h C- RAS This sect ion covers t he refinem ent of t he business- obj ect m odel int o an init ial UML com ponent m odel. This is t he convergent refinem ent I I ( convergent UML represent at ion) act ivit y of t he analysis- by- design w ork flow and is support ed by t he convergent refinem ent assist ant ( C- RAS) m odule. As det ailed in Chapt ers 6 and 7, t he C- RAS bridges t he gap bet ween business m odeling and UML refinem ent using convergent m apping pat t erns and rules as defined by t he OPEN Consort ium . The result of t his refinem ent st ep is a convergent design t hat preserves direct visibilit y of t he business m odel in t he result ing UMLbased J2EE/ EJB com ponent m odel. This st ep increases qualit y and proj ect t ransparency by providing bidirect ional t racking t o t he original requirem ent s as well as bet ween rapid- developm ent it erat ions. ƒ ƒ ƒ ƒ

This sect ion cont ains t he following subsect ions: St art ing C- RAS Refining t he account business obj ect Refining t he t ransfer business obj ect Model verificat ion St a r t ing C- RAS St art t he ArcSt yler, open t he proj ect file iBa nk .a spr j t hat you creat ed in t he previous sect ion, and click on t he C- RAS but t on in right corner of t he ArcSt yler t ool bar t o act ivat e t he C- RAS t ool. Figure 8.5 shows t he yet unrefined m odel. The elem ent s visible in t he hierarchy browser t o t he left of t he figure are t he business obj ect s from t he C- BOM, each

-234-

Convergent Architecture

Chapter 8: Tutorial Example

cont aining it s list of as yet unrefined responsibilit ies. Each unrefined elem ent is labeled wit h an exclam at ion m ark ( ! ) .

Figur e 8 .5 : The init ially unrefined business m odel.

ƒ ƒ ƒ

Refining a business obj ect m eans refining it s responsibilit ies. I n general, a responsibilit y can be refined t o one of t he follow ing UML m odel elem ent s wit hin t he cont ext of a com ponent int erface: At t ribut e Operat ion Associat ion The refinem ent pat t erns suggest t hat responsibilit ies for Know ing are norm ally refined t o at t ribut es or associat ions, whereas responsibilit ies for Doing are refined t o operat ions. A responsibilit y is refined by select ing it in t he browser and using it s Re fine → < Re finingEle m e nt > cont ext m enu.

Re fining t he Accoun t Busine ss Obj e ct Refine t he responsibilit ies of t he Accou nt obj ect as follows: 1. Refine t he Know ba la nce responsibilit y wit h an at t ribut e, a ccount N um be r , of t ype st r ing. Figure 8.6 shows t he result of t his procedure.

-235-

Convergent Architecture

2.

Chapter 8: Tutorial Example

Figur e 8 .6 : Refining t he Know account num ber responsibilit y. Sim ilarly, refine t he Know ba la nce responsibilit y wit h an at t ribut e, ba la nce , of t ype double . Figure 8.7 shows t he result of t his procedure.

-236-

Convergent Architecture

3.

Chapter 8: Tutorial Example

Figur e 8 .7 : Modeling t he balance at t ribut e. Refine t he M a k e de posit responsibilit y wit h an operat ion, m a k e D e posit , wit h ret urn t ype < none > and a param et er, a m ount , of t ype double and direct ion I N . Figure 8.8 show s t he result of t his procedure.

-237-

Convergent Architecture

4.

Chapter 8: Tutorial Example

Figur e 8 .8 : Modeling t he m akeDeposit ( ) operat ion. Sim ilarly, refine t he M a k e w it hdr a w a l responsibilit y wit h an operat ion, m a k e - W it hdr a w a l, wit h ret urn t ype < none > and a param et er, a m ount , of t ype double and direct ion I N .

Re fining t he Tr a nsfe r Busine ss Obj e ct Now we refine t he Tr a n sfe r obj ect . 1. Refine t he Know sour ce a ccount wit h an at t ribut e, sour ce , of obj ect t ype Accou nt . Figure 8.9 shows t his procedure.

-238-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .9 : Modeling t he source at t ribut e. Sim ilarly, refine t he Know de st ina t ion a ccount responsibilit y wit h an at t ribut e, de st ina t ion, of t ype Account . 3. Refine t he Know a m ount t o be t r a nsfe r r e d responsibilit y wit h an at t ribut e, a m ount , of t ype double . 4. Refine t he Ex e cut e t r a nsfe r responsibilit y wit h an operat ion, e x e cut e , wit h ret urn t ype < none > and no param et ers. Now t he refinem ent of t he business- m odel obj ect s t o UML convergent com ponent s has been com plet ed, as indicat ed by t he checkm ark in t he Figure 8.10. The checkm ark indicat es t hat t he refinem ent of t he m odel elem ent is com plet ed.

2.

-239-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .1 0 : Refined t o UML com ponent s. M ode l Ve r ifica t ion The C- RAS m odule provides a m odel- verificat ion m echanism t o verify t he st ruct ural correct ness and com plet eness of t he UML m odel. You can verify single m odel elem ent s or t he ent ire m odel using t he elem ent 's Ve r ify cont ext m enu. The verifier not ifies you as t o t he result s of t he validat ion. I f t he validat ion is not successful, you will get warnings or error m essages. I n t he case of errors, t he m odel m ust be fixed in order t o m aint ain int egrit y as defined by t he archit ect ural st yle. At t his point , t he UML convergent com ponent m odel has been creat ed.

J2 EE/ EJB M ode lin g w it h C- REF/ UM L This sect ion covers t he t echnical refinem ent of t he UML com ponent m odel. This is t he convergent refinem ent I I I ( convergent UML refinem ent ) act ivit y of t he analysis- by- design work flow, which is support ed by t he convergent EJB/ UML refiner for Rat ional Rose ( C- REF) . The C- REF m odule assist s you in refining t he UML m odel according t o t he UML m odeling st yle and t echnology proj ect ion, as described in Chapt er 7. The C- REF provides design assist ant s and default s t o t echnically refine all com ponent s and t heir relat ionships. This sim plifies m odeling while st ill perm it t ing ext ensions and adj ust m ent s by expert s. ƒ ƒ

This sect ion cont ains t he following subsect ions: St art ing t he C- REF Modeling t he account com ponent

-240-

Convergent Architecture

ƒ ƒ ƒ

Chapter 8: Tutorial Example

Modeling t he t ransfer com ponent Modeling deployable com ponent s Model verificat ion St a r t ing t he C- REF The C- REF m odule operat es as an archit ect ural shell around Rat ional Rose. Perform ance, com pat ibilit y, and ease of use from wit hin t he Rose environm ent are a high priorit y. To achieve t his, t he ArcSt yler consolidat es it s open UML/ XML reposit ory ( C- MOD) wit h t he Rose int ernal reposit ory. This consolidat ion is encapsulat ed properly and, as such, is t ransparent t o all m odules of t he ArcSt yler. The consolidat ed form at is referred t o as t he Rose nat ive form at . The conversion bet ween t he Rose nat ive form at and t he ArcSt yler UML/ XML reposit ory is bidirect ional and lossless. Also, it only needs t o be carried out when you m ove back and fort h bet ween t he C- RAS and C- REF m odules. To m ove from t he C- RAS m odule int o t he Rose- cent ric C- REF, you im port t he ext ernal C- MOD reposit ory int o it s corresponding C- REF/ Rose reposit ory in Rose ( Rose nat ive form at ) . Once in t he C- REF/ Rose environm ent , m odeling proceeds using Rose wit hin t he ArcSt yler shell. All m odules use t he C- REF/ Rose nat ive form at . The ArcSt yler C- MOD reposit ory can be st ored and reloaded in t he Rose nat ive form at or export ed t o t he ext ernal C- MOD at any t im e.

AM FL Y

Fr om C- RAS t o C- REF

TE

When you have com plet ed t he init ial UML refinem ent in C- RAS, click on t he Rose but t on in t he right corner of t he ArcSt yler t ool bar. This saves t he current proj ect and dom ain configurat ion, st art s Rat ional Rose, and aut om at ically loads t he current ArcSt yler proj ect file, iBa nk .a spr j . You will be asked t o im port t he m odel inform at ion from t he ArcSt yler reposit ory, iBa nk .a sr e p, associat ed w it h t he proj ect . A new Rose m odel, iBa nk .m dl, will be creat ed as t arget of t he im port ( or an exist ing iBa nk .m dl w ill be loaded as t he t arget ) . Aft er t he im port is com plet ed, save t he Rose m odel using t he Rose m enu File → Sa ve . The new Rose m odel, iBa nk .m dl, is aut om at ically associat ed wit h t he ArcSt yler proj ect file, iBa nk .a spr j . Once t he reposit ory has been im port ed, t his im port does not have t o be repeat ed unless you explicit ly m ove back and m ake changes in t he C- BOM. The reposit ory inform at ion has been aut om at ically st ored in Rose, and t he proj ect const ellat ion has been st ored in t he ArcSt yler proj ect file. From now on, a double- click on t he iBa nk .a spr j file w ill st art t he C- REF/ Rose. At t his point , t he C- REF/ Rose environm ent should resem ble Figure 8.11.

-241-

Team-Fly®

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .1 1 : The init ial C- REF/ Rose m odel.

ƒ ƒ ƒ ƒ

M ode lin g t he Accou nt Com pone nt I n t his sect ion you will m odel or t une t he following EJB propert ies of t he Account com ponent : Ent it y bean w it h cont ainer- m anaged persist ence ( CMP) At t ribut e a ccou nt N um be r as key at t ribut e Default cr e a t e ( ) m et hod wit h em pt y param et er list User- defined cr e a t e ( ) m et hod wit h param et er a ccou nt N um be r I n t he UML m odel, t hese propert ies are m anaged in t he com ponent 's ArcSt yler propert y sheet s.

EJB Pr ope r t ie s ƒ ƒ ƒ ƒ

The EJB propert ies of t he Account com ponent are specified in t he Ar cSt yle r EJB 1 .1 propert y sheet of com ponent 's Rose specificat ion dialog. The following propert ies are relevant for t he Accou nt com ponent : M ode lin gSt yle —Com pa ct . The bean is m odeled using t he com pact bean pat t ern. Be a n H om e N a m e —< e m pt y> . This specifies t he JNDI nam e t he cont ainer uses t o look up t he hom e int erface. I f not hing is specified, t he com ponent nam e will be used. Be a nType —Ent it y. Pe r sist e nce M a na ge m e nt —Cont a ine r . The Accou nt com ponent is im plem ent ed as ent it y bean wit h cont ainer- m anaged persist ence.

-242-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ ƒ

Chapter 8: Tutorial Example

I sRe e nt r a nt —Fa lse . The ent it y bean is not reent rant . Tr a nsa ct ionType —Cont a ine r . The t ransact ion m anagem ent is handled by t he cont ainer. Cont a ine r Tr a nsa ct ion—Re quir e d. The cont ainer invokes t he bean wit h a valid t ransact ion cont ext . See t he EJB 1.1 specificat ion. Com m it Opt ion—Ca r t r idge D e fa u lt . This specifies t hat t he dat abase access during a t ransact ion is defined by t he t echnology proj ect ion cart ridge. Ge nD fI t Fa ct or ie s—Em pt yPa r a m e t e r List . A default creat e m et hod wit h em pt y param et er list is generat ed in t he bean's hom e int erface. Ge nFindAllI nst a nce s—Tr ue . A findAllI nst ances( ) m et hod is generat ed in t he bean's hom e int erface. Figure 8.12 shows t he com plet ed Ar cSt yle r EJB 1 .1 propert y sheet for t he Account com ponent .

Figur e 8 .1 2 : EJB propert ies of t he account com ponent .

-243-

Convergent Architecture

Chapter 8: Tutorial Example

By default , all nonderived at t ribut es of t he CMP ent it y bean are st ored persist ent ly. Now you will specify t he a ccou nt N um be r at t ribut e of t he Account com ponent as key at t ribut e. This is done in t he Ar cSt yle r EJB 1 .1 propert y sheet of t he at t ribut e's Rose specificat ion dialog by set t ing t he Pa r t OfPr im a r yKe y propert y t o Tr ue , as shown in Figure 8.13.

Figur e 8 .1 3 : EJB propert ies of t he account Num ber at t ribut e.

Use r - D e fin e d Fa ct or y M e t h od You will furt her cust om ize and t une t he design by m odeling a user- defined fact ory m et hod t hat t akes t he a ccount N um be r at t ribut e as param et er. To do so, proceed as follow s: 1. Add a new operat ion, cr e a t e , wit h t he st ereot ype cre a t e t o t he Account com ponent . 2. Add a param et er, a ccount N um be r, of t ype st r ing t o t he operat ion. The t echnical refinem ent of t he Accou nt com ponent is now com plet e.

-244-

Convergent Architecture

ƒ ƒ

Chapter 8: Tutorial Example

M ode lin g t he Tr a nsfe r Com pone nt I n t his sect ion you will m odel t he following EJB propert ies of t he Tr a nsfe r com ponent : St at eful session bean Default creat e m et hod wit h all at t ribut es as param et ers

EJB Pr ope r t ie s ƒ ƒ ƒ ƒ ƒ ƒ ƒ

The EJB propert ies of t he Tr a nsfe r com ponent are specified in t he Ar cSt yle r EJB 1 .1 propert y sheet of t he com ponent 's Rose specificat ion dialog. The following propert ies are relevant for t he Tr a nsfe r com ponent : M ode lin gSt yle —Com pa ct . Be a n H om e N a m e —< e m pt y> . Be a nType —Se ssion. St a t e M a n a ge m e nt —St a t e ful. The Tr a nsfe r com ponent is im plem ent ed as st at eful session bean. Tr a nsa ct ionType —Cont a ine r . Cont a ine r Tr a nsa ct ion—Re quir e d. Ge nD fI t Fa ct or ie s—AllAt t r ibut e sAsPa r a m e t e r s. A default creat e m et hod wit h all at t ribut es as param et ers is generat ed in t he bean's hom e int erface. Figure 8.14 shows t he com plet ed Ar cSt yle r EJB 1 .1 propert y sheet for t he Tr a nsfe r com ponent .

-245-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .1 4 : EJB propert ies of t he Transfer com ponent . The t echnical refinem ent of t he Tr a nsfe r com ponent is now com plet e.

1. 2. 3. 4.

M ode lin g D e ploya ble Com pon e nt s Now you will m odel t he assem bly in t erm s of it s individual deployable com ponent s. At t his point , t he assem bly includes an EJB archive t hat packages t he Account and Tr a nsfe r com ponent s as well as an EJB client archive needed by t he Web accessors. The Web applicat ion will be developed lat er in t he t ut orial, but we want t o first deploy and t est t he business com ponent s in t he EJB cont ainer. Deployable com ponent s are m odeled in a package in t he Com pone nt V ie w of t he Rose m odel. To m odel an EJB archive, proceed as follow s: Add a new package, libs, t o t he Com pone nt Vie w . Add a new com ponent , m ode l, w it h t he st ereot ype EJB Archive t o t he libs package. Assign t he Account and Tr a nsfe r com ponent s t o t he EJB archive by dragging t he com ponent s t o t he m ode l com ponent . Make sure t hat t he Set in t he cart ridge- specific propert y sheet of t he m ode l com ponent ( for exam ple, BAS 4 .x , W LS 5 .1 ) is set t o EJBAr chive , and check t he Te st Se r ve r Addr e ss and Te st Se r ve r Por t propert ies in t his propert y sheet .

-246-

Convergent Architecture

Chapter 8: Tutorial Example

The Web accessors or any ot her client s will need an EJB client archive com ponent as well, which you also can creat e now: 1. Add a new com ponent , st ubs, w it h t he st ereot ype EJBClie nt Ar chive t o t he libs package. 2. Drag and drop t he Accou nt and Tr a nsfe r beans t o t he client archive. 3. Make sure t hat t he Se t in t he cart ridge- specific propert y sheet of t he st ubs com ponent is set t o EJBClie nt Ar chive , and check t he Te st Se r ve r Addr e ss and Te st Se r ve r Por t propert ies in t his propert y sheet .

ƒ ƒ ƒ ƒ

M ode l Ve r ifica t ion I t is now t im e check t he st ylist ic int egrit y of t he UML m odel and m ake sure t hat it can be proj ect ed successfully t o t he select ed infrast ruct ure. The C- REF t ool provides a configurable m odel- verificat ion m echanism ( also known as m odel validat ion) t o validat e t he UML m odel according t o t he requirem ent s of t he archit ect ural st yle. The following aspect s can be verified: St ruct ural correct ness UML const raint s Rat ional Rose const raint s Technical feasibilit y ( Java const raint s, cont ainer- specific J2EE/ EJB const raint s) You can verify single m odel elem ent s or t he ent ire m odel. I f problem s are found, m essages r egarding t he problem s, t heir causes, and t heir severit ies are present ed. Warning m essages m anifest dubious or subopt im al m odel const ellat ions, and error m essages indicat e problem s t hat m ust be fixed in order t o rem ain st yle- conform . At t his point , you have a refined t he UML m odel of your business com ponent s and assem bly com ponent s t o t he level w here t he convergent generat or ( C- GEN) generat or, and t echnology proj ect ion cart ridge can t ake over and generat e a deployable infrast ruct ure.

Ge ne r a t in g t h e EJB Com pon e n t s w it h C- GEN This sect ion covers t he code- generat ion st eps in t he archit ect ural I DE t hat essent ially support all t he const ruct ion- phase w ork flows in t he CA process. I n t his st ep, t he C- GEN m odule and t he t echnology proj ect ion cart ridge are act ivat ed from t he C- REF UML m odel t o creat e m aj or port ions of t he deploym ent infrast ruct ure as well as t he t est and build environm ent . As explained in Chapt er 7, t he dept h and widt h of t his infrast ruct ure are so ext ensive t hat it is referred t o as fan- out . The C- GEN is a powerful JPyt hon- based generat or engine t hat uses one or m ore t echnology proj ect ion cart ridges t o program and drive t he generat ion process. A cart ridge provides t he t em plat es, script s, and opt im izat ion rules for a part icular runt im e environm ent ( for exam ple, an J2EE/ EJB cont ainer) . Moreover, it supplies t he m odel verifiers used by t he C- REF m odule ( see preceding sect ion) t o verify t he t echnical feasibilit y of t he UML m odel wit h respect t o t he t arget t echnology. ƒ ƒ

This sect ion cont ains t he following subsect ions: Configuring t he code generat or Running t he code generat or

-247-

Convergent Architecture

Chapter 8: Tutorial Example

Configur in g t he Code Ge ne r a t or

ƒ ƒ ƒ ƒ ƒ

Before you can st art wit h t he code generat ion, you m ust configure t he code generat or. I n part icular, you m ust specify t he following: A source code out put direct ory A t echnology proj ect ion cart ridge for t he t arget runt im e environm ent A t em plat e pat h specifying where t he t em plat es ( and t em plat e ext ensions) are locat ed Dat abase configurat ion inform at ion Configurat ion of t he t ools used by t he build process ( for exam ple, J2EE/ EJB cont ainer, Tom cat servlet engine) The code generat or is configured in t he C- GEN t ab of t he ArcSt yler configurat ion dialog.

Th e Ge n e r a t e Pa n e l ƒ ƒ ƒ

I n t he Ge ne r a t e panel of t he C- GEN t ab, you m ust specify t he following: Ge ne r a t e d Sour ce D ir e ct or y. This specifies t he source code out put direct ory. Te m pla t e D ir e ct or y. This specifies t he pat h where t he code generat or searches for t he t em plat es. Pr oj e ct N a m e . This specifies t he nam e of t he proj ect , for exam ple, I Ba nk Tut or ia l. Figure 8.15 shows t he com plet ed configurat ion of t he Ge ne r a t e panel.

-248-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .1 5 : The Generat e panel.

Th e Pr oj e ct ions Pa n e l ƒ ƒ

I n t he Pr oj e ct ions panel of t he C- GEN t ab, you m ust specify t he follow ing: Chose n Te chnology Pr oj e ct ions. This specifies t he t echnology proj ect ion cart ridges t o act ivat e. Each cart ridge provides cart ridge- specific propert ies t hat m ust be configured. To configure t hese propert ies, select t he proj ect ion.t pr file in t he Ch ose n Te chnology Pr oj e ct ions field. Figure 8.16 shows t he Pr oj e ct ions panel for t he BEA Weblogic server cart ridge.

-249-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .1 6 : The Proj ect ions panel.

Th e D a t a ba se Pa n e l I n t he D a t a ba se panel of t he C- GEN t ab, you m ust configure t he dat abase used by t he cont ainer t o st ore ent it y beans wit h cont ainer- m anaged persist ence. Usually, an EJB cont ainer provides a default dat abase. For sim plicit y, we will use t his default dat abase in t his t ut orial. To do so, choose Ca r t r idge D e fa ult from t he D a t a ba se Type drop- down m enu. The default configurat ion for t he cont ainer's default dat abase will now be generat ed aut om at ically int o t he EJB deploym ent descript ors. All ot her fields can be left em pt y for t he default dat abase. For det ails about t he dat abase configurat ion and t he default dat abase of a part icular EJB cont ainer, please refer t o t he corresponding cart ridge docum ent at ion.

Th e Tools Pa n e l I n t he Tools panel of t he C- GEN t ab, you m ust configure t he t ools used by t he t arget t echnology proj ect ion. I n part icular, you m ust configure t he inst allat ion root of your EJB cont ainer because t his m ay vary on any given m achine.

-250-

Convergent Architecture

Chapter 8: Tutorial Example

To do so, select t he t arget t ool from t he Choose t he t ool you w a nt t o configur e drop- down m enu. I n t he I nst a lla t ion field you m ust specify t he inst allat ion pat h of t he t ool. Use t he Br ow se but t on t o open a direct ory select or dialog. I f required by t he t ool, you m ay specify a license key in t he Lice nse field.

TE

AM FL Y

For det ails about t he t ool configurat ion needed for your t echnology proj ect ion cart ridge, please refer t o t he appropriat e cart ridge docum ent at ion. Figure 8.17 shows t he Tools panel for t he BEA Weblogic server cont ainer.

Figur e 8 .1 7 : The Tools panel. Now t hat you have configured t he code generat or, save t he configurat ion using t he Rose m enu Tools → Ar cSt yle r → Sa ve Con figur a t ion.

ƒ ƒ ƒ

Run nin g t he Code Ge ne r a t or Now run t he code generat or. I n t he Rose browser, select t he ent ire Logica l V ie w package, and use it s Ar cSt yle r → Ge ne r a t e cont ext m enu t o generat e all art ifact s. These art ifact s include t he following at t his point . The JSP and ot her Web art ifact s w ill be generat ed in lat er sect ion using an accessor cart ridge. Java sources ( hom e int erface, rem ot e int erface, bean im plem ent at ion class) . The Java sources are generat ed in t he % SRC% / < cont a ine r _ id> _ ge n / iba nk direct ory, where % SRC% is t he source- code out put direct ory you configured in t he Ge ne r a t e panel. Default t est client .

-251-

Team-Fly®

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ ƒ ƒ

Chapter 8: Tutorial Example

The default t est client , m ode lTe st Clie nt .j a va , is generat ed in t he % SRC% / com pone nt s/ libs/ m ode l direct ory. St andard deploym ent descript or. The st andard deploym ent descript or is generat ed in t he % SRC% / com pone nt s/ libs/ m ode l/ M ETA- I N F direct ory. Cont ainer- specific deploym ent descript ors. The cont ainer- specific deploym ent descript ors are generat ed in t he % SRC% / com pone nt s/ libs/ m ode l/ < cont a ine r _ id> / M ETA- I N F direct ory. Cont ainer- specific build support files. The cont ainer- specific build support files are generat ed in t he % SRC% / com pone nt s/ libs/ m ode l/ < cont a ine r _ id> direct ory. Progress and inform at ion pert aining t o t he code generat ion are logged t o t he Rose log window. Figure 8.18 shows an exam ple of t he generat or out put in t he log window.

Figur e 8 .1 8 : Rose log window.

Bu ildin g, D e ployin g, a n d Te st in g t h e EJB Com pon e n t s This sect ion shows how t o use one of several build, deploy, and t est const ellat ions support ed by t he archit ect ural I DE. I t exhibit s support for t he im plem ent at ion cycle work flows, t est work flows, and several aspect s of t he deploym ent and m onit oring work flow. ƒ ƒ ƒ ƒ

Aft er t he code has been generat ed, t he following t asks are at hand: Cust om ize t he code. Build t he EJB JAR file. Deploy t he EJB JAR file in a t est cont ainer. Test t he EJB com ponent s using t he default t est client .

-252-

Convergent Architecture

ƒ ƒ

Chapter 8: Tutorial Example

The sim ple, ANT- based execut ion of t hese t asks is covered in t he following subsect ions: Code cust om izat ion Build support Code Cust om iza t ion I n t his sect ion, you will im plem ent som e cust om business logic in t he Account and Tr a nsfe r beans. Moreover, you will im plem ent cust om t est code in t he default t est client . As explained in Chapt er 7, t he code generat or uses t he concept of prot ect ed areas t o support round- t rip developm ent . Prot ect ed areas are code segm ent s t hat are preserved across subsequent runs of t he code generat or. Cust om business logic and ot her inform at ion t hat cannot be specified in t he UML m odel are ent ered in t hese prot ect ed areas. You can use any edit or t o cust om ize t he source code. How ever, Borland's Java I DE is explicit ly support ed by t he archit ect ural I DE for t his purpose. A JBuilder proj ect file, m ode l.j pr , was generat ed in t he % SRC% / com pone nt s/ libs/ m ode l/ < cont a ine r _ id> direct ory. I t cont ains inform at ion regarding t he Java sources, deploym ent descript ors, t est packages, and ot her JBuilder inform at ion associat ed wit h t he EJB archive com ponent , m ode l, t hat you creat ed in t he previous C- REF sect ion.

Th e Accou n t Be a n .j a va File ƒ ƒ ƒ

The Account Be a n.j a va file w as generat ed int o t he % SRC% / < cont a ine r _ id> _ ge n / iba nk direct ory. I n t his file you m ust im plem ent t he following m et hods: e j bCr e a t e ( ) for t he cust om , user- defined fact ory m et hod you added previously m a k e D e posit ( ) m a k e W it hdr a w a l ( ) The following code fragm ent shows t he im plem ent at ion of t he user- defined fact ory m et hod: public j ava.lang.St ring ej bCreat e( j ava.lang.St ring account Num ber) t hrows Creat eExcept ion { / * START OF PROTECTED AREA < < ej bCreat e: st ring> > * / / / @t odo - init ialize all key at t ribut es / / insert cust om code here / / t his ret urn value is ignored by t he cont ainer ( EJB 1.1 Spec, §9.4.2) t his.account Num ber = account Num ber; ret urn null; / * END OF PROTECTED AREA 2022d7ea000000b5 * / } The following code fragm ent shows t he im plem ent at ion of t he m a k e D e posit ( ) m et hod: public void m akeDeposit ( double am ount )

-253-

Convergent Architecture

Chapter 8: Tutorial Example

{ / * START OF PROTECTED AREA < < m akeDeposit : double> > * / / / insert cust om code here set Balance( get Balance( ) + am ount ) ; / * END OF PROTECTED AREA 9d700c2d0000002b * / } The m a k e W it hdr a w a l ( ) m et hod is im plem ent ed analogously as follow s: public void m akeDeposit ( double am ount ) { / * START OF PROTECTED AREA < < m akeDeposit : double> > * / / / insert cust om code here set Balance( get Balance( ) - am ount ) ; / * END OF PROTECTED AREA 9d700c2d0000002b * / }

Th e Tr a n sfe r Be a n .j a va File The Tr a nsfe r Be a n.j a va file also was generat ed int o t he % SRC% / < cont a ine r _ id> _ ge n / iba nk direct ory. I n t his file you m ust im plem ent t he e x e cut e ( ) m et hod. This is done as follows: public void execut e( ) { / * START OF PROTECTED AREA < < execut e> > * / / / insert cust om code here t ry { source.m akeWit hdraw al( am ount ) ; dest inat ion.m akeDeposit ( am ount ) ; } cat ch( Throwable ex) { ex.print St ackTrace( Syst em .err) ; } / * END OF PROTECTED AREA 9d700c2d0000002b * / }

Th e m ode lTe st Clie n t .j a va File The m ode lTe st Clie nt .j a va file was generat ed int o t he % SRC% / com pone nt s/ libs/ m ode l direct ory. I n t his file you m ust im plem ent t he cust om t est code. The t est code is im plem ent ed wit hin t he < < m a in > > prot ect ed area. The following code fragm ent shows an exam ple im plem ent at ion: / * START OF PROTECTED AREA < < m ain> > * /

-254-

Convergent Architecture

Chapter 8: Tutorial Example

/ / sam ple t ype cast ing inst ruct ion / / Sam pleHom e hom e = ( Sam pleHom e) j avax.rm i.Port ableRem ot eObj ect .narrow ( ref,Sam pleHom e.class) ; / / insert your cust om code here Syst em .out .print ln( "Welcom e t o t he I Bank Tut orial! " ) ; Obj ect ref = cont ext .lookup( "Account " ) ; Account Hom e hom e = ( Account Hom e) j avax.rm i.Port ableRem ot eObj ect .narrow ( ref,Account Hom e.class) ; Account sourceAccount = null; Account dest inat ionAccount = null; t ry { / / t ry t o lookup source account obj ect sourceAccount = hom e.findByPrim aryKey( " 00001" ) ; dest inat ionAccount = hom e.findByPrim aryKey( " 00002" ) ; } cat ch( FinderExcept ion e) { / / account does nor exist yet so value of sourceAccount rem ains null Syst em .out .print ln( " Source account not found on server." ) ; } cat ch ( Rem ot eExcept ion e) { Syst em .out .print ln( " - > Rem ot e Except ion "+ e) ; Syst em .exit ( 1) ; } t ry { / / creat e account s if previous find was unsuccessfull if ( sourceAccount = = null) { Syst em .out .print ln( "Creat e source account 's rem ot e int erface" ) ; sourceAccount = ( Account ) hom e.creat e( " 00001" ) ; Syst em .out .print ln( "- > Account Bean creat ed" ) ; } if ( dest inat ionAccount = = null) { Syst em .out .print ln( "Creat e dest inat ion account 's rem ot e int erface" ) ; dest inat ionAccount = ( Account ) hom e.creat e( " 00002" ) ; Syst em .out .print ln( "- > Account Bean creat ed" ) ; } / / put m oney on source account Syst em .out .print ln( " Deposit 1000 on account " + " 00001" ) ;

-255-

Convergent Architecture

Chapter 8: Tutorial Example

sourceAccount .m akeDeposit ( 1000.0) ; / / show balance of account s before t ransfer Syst em .out .print ln( "Balances of account s before t ransfer: " ) ; Syst em .out .print ln( " Balance of account " + sourceAccount .get Account Num ber( ) + " is " + sourceAccount .get Balance( ) ) ; Syst em .out .print ln( " Balance of account " + dest inat ionAccount .get Account Num ber( ) + " is " + dest inat ionAccount .get Balance( ) ) ; / / creat e t ransfer obj ect Syst em .out .print ln( " Creat e t ransfer rem ot e int erface" ) ; ref = cont ext .lookup( " Transfer" ) ; TransferHom e hom e2 = ( TransferHom e) j avax.rm i.Port ableRem ot eObj ect .narrow ( ref,TransferHom e.class) ; Transfer t ransfer = ( Transfer) hom e2.creat e( sourceAccount ,dest inat ionAccount ,300) ; Syst em .out .print ln( " - > TransferBean creat ed" ) ; / / execut e t ransfer Syst em .out .print ln( " Making t ransfer of 300 from account " + "00001" + " t o account " + " 00002" ) ; t ransfer.execut e( ) ; / / show balance of account s aft er t ransfer Syst em .out .print ln( " Balances of account s aft er t ransfer: " ) ; Syst em .out .print ln( " Balance of account " + sourceAccount .get Account Num ber( ) + " is " + sourceAccount .get Balance( ) ) ; Syst em .out .print ln( " Balance of account " + dest inat ionAccount .get Account Num ber( ) + " is " + dest inat ionAccount .get Balance( ) ) ; j ava.ut il.Collect ion col = hom e.findAllI nst ances( ) ; j ava.ut il.I t erat or it = col.it erat or( ) ; Syst em .out .print ln( " Found t he following account s: " ) ; w hile ( it .hasNext ( ) ) {

-256-

Convergent Architecture

Chapter 8: Tutorial Example

Account acc = ( Account ) j avax.rm i.Port ableRem ot eObj ect .narrow ( it .next ( ) ,Account .class) ; Syst em .out .print ln( "Account " + acc.get Account Num ber( ) ) ; } ret urn; } cat ch ( Rem ot eExcept ion e) { Syst em .out .print ln( " - > Rem ot e Except ion: "+ e) ; e.print St ackTrace( ) ; Syst em .exit ( 1) ; } cat ch ( Except ion e) { Syst em .out .print ln( " - > Except ion: " + e) ; e.print St ackTrace( ) ; Syst em .exit ( 1) ; } / * END OF PROTECTED AREA 88807f8b000000bb( C) * / Moreover, you m ust im plem ent t he < < im por t > > prot ect ed area at t he beginning of t he file as follows: / * START OF PROTECTED AREA < < im port > > * / / / insert your im port st at em ent s im port ibank.* ; im port j avax.ej b.* ; im port j ava.rm i.* ; / * END OF PROTECTED AREA d86cd7c700000022( C) * / Build Suppor t I n t his sect ion you will build t he EJB archive, m ode l.j a r , and t he EJB client archive, st ubs.j a r . The ArcSt yler provides ext ensive support for building, deploying, and t est ing your EJB com ponent syst em . This includes bot h ANT- based com m and- line build support and Java I DE- based build support .

AN T- Ba se d Bu ild Su ppor t The C- GEN generat ed ANT script s for t he EJB archive com ponent , m ode l, and t he EJB client archive com ponent , st ubs, in t he % SRC% / com pone nt s/ libs/ m ode l/ < cont a ine r _ id> and % SRC% / com pone nt s/ libs/ st ubs/ < cont a ine r _ id> direct ories, respect ively. The build t arget s are defined in t he ANT build file, build.x m l. The Java propert ies needed for t he build process are defined in t he build.pr ope r t ie s file. Bot h files cont ain prot ect ed areas so t hat you can cust om ize t he build process at any t im e. To build, deploy, and t est t he EJB archive, open a com m and shell and go t o t he % SRC% / com pone nt s/ libs/ m ode l/ < cont a ine r _ id> direct ory. Now act ivat e t he following build t arget s. These are t he crit ical- pat h subset of t he available build t arget s.

-257-

Convergent Architecture

ƒ ƒ ƒ ƒ

Chapter 8: Tutorial Example

Com pile t he Java sources and generat e t he EJB JAR file, m ode l.j a r , using t he following com m and: build. The JAR file is st ored in t he % SRC% / com pone nt s/ libs direct ory. St art t he EJB cont ainer and deploy t he EJB JAR file using t he following com m and: build r u nSe r ve r . Run t he default t est client , m ode lTe st Clie nt , using t he following com m and: build r u nClie nt . To build t he EJB client archive, open a com m and shell and go t o t he % SRC% / com pone nt s/ libs/ st ubs/ < cont a ine r _ id> direct ory. The m ain t arget t o build t he EJB client archive is build. I t com piles t he Java sources and generat es t he EJB client JAR file, st ubs.j a r . The JAR file is st ored in t he % SRC% / com pone nt s/ libs direct ory. I n general, t he build process is highly cont ainer- specific. For det ails, please refer t he respect ive t echnology proj ect ion cart ridge docum ent at ion. One such cart ridge docum ent is present ed in t he bonus chapt er on t he Web sit e, which covers t he det ails of t he t echnology proj ect ion com ponent in reference m anual form . Ot her cart ridge docum ent at ion is also available via t he Convergent Archit ect ure Web sit e. Figure 8.19 shows t he out put from t he default t est client as st art ed from t he com m and line.

Figur e 8 .1 9 : Test client out put for t he iBank t ut orial.

-258-

Convergent Architecture

Chapter 8: Tutorial Example

I D E- Ba se d Bu ild Su ppor t I n t he previous st eps, build support for Borland's Java I DE JBuilder also w as generat ed aut om at ically. The respect ive JBuilder proj ect files, libraries, and configurat ions were generat ed int o t he % SRC% / com pone nt s/ libs/ m ode l/ < cont a ine r _ id> and % SRC% / com pone nt s/ libs/ st ubs/ < cont a ine r _ id> direct ories, respect ively. The advant age of Java I DE- based build support is t hat you can use t he I DE for visual debugging and t est ing. For det ails, refer t he respect ive t echnology proj ect ion cart ridge docum ent at ion. One such cart ridge docum ent is present ed in t he bonus chapt er on t he Web sit e, which covers t he det ails of t he t echnology proj ect ion com ponent in reference m anual form . Ot her cart ridge docum ent at ion is also available via t he Convergent Archit ect ure Web sit e.

M ode lin g t h e W e b Acce ssor s in C- REF I n t he preceding sect ions you com plet ed developm ent of t he business com ponent s. The business com ponent s are now deployed and ready t o do business as EJB com ponent s in an applicat ion server. I n t he rem ainder of t his t ut orial you will t ake on t he role of accessor developer ( see Chapt er 5) and develop t he accessor com ponent s for Web access—a graphic user int erface ( GUI ) t hat enables client s t o int eract wit h t he EJB com ponent syst em . This will be achieved according t o t he CA process as defined in Chapt er 6 wit h support of t he archit ect ural I DE as described in Chapt er 7.

ƒ

You will proceed as follows: Creat e accessor m odels in UML using t he C- REF/ Rose m odule. Generat e accessor infrast ruct ure for a Web- channel using t he JSP accessor cart ridge. Build, deploy, and t est t he Web user int erfaces.

ƒ ƒ ƒ

This sect ion covers t he UML m odeling st eps. I t cont ains t he following subsect ions: Generat ing default accessor m odels Ext ending t he default accessor m odel Modeling t he Web applicat ion deploym ent com ponent

ƒ ƒ

Ge ne r a t ing D e fa ult Acce ssor M ode ls

ƒ ƒ ƒ ƒ ƒ

The accessor m odeling st yle and it s aut om at ion support in t he archit ect ural I DE enable us t o generat e default accessor m odels based on an exist ing business com ponent m odel. These default accessors are designed t o cover t he m ost com m on accessor use- case scenarios. The m ost com m on scenarios involve t he following client int eract ion wit h t he business com ponent syst em : Show a part icular inst ance of a business com ponent . Show all exist ing inst ances of a business com ponent . Creat e an inst ance of a business com ponent . Rem ove a part icular inst ance of a business com ponent . Modify a part icular inst ance of a business com ponent . For det ails on default accessors and t heir underlying design, consult t he bonus chapt er and ot her inform at ion available on t he Convergent Archit ect ure Web sit e.

-259-

Convergent Architecture

Chapter 8: Tutorial Example

I n t his t ut orial we will use t he default accessor m odel generat or t o generat e accessors t o m anipulat e Account com ponent s: creat e new account s and edit or delet e exist ing account s. To do so, proceed as follows: 1. Select t he Account com ponent in t he C- REF/ Rose browser and use it s Ar cSt yle r → Acce ssor s → Cr e a t e → Colle ct ion Edit or accessor cont ext m enu. This will creat e a subpackage in t he iBa nk package, D e fa ult a cce ssor sPa ck a ge . 2. I n order t o use brief not at ions in your m odel, renam e t he D e fa ult a cce ssor sPa ck a ge package int o GUI package. Figure 8.20 shows t he new default accessor package wit h it s new nam e, GUI .

Figur e 8 .2 0 : The default accessor package.

ƒ ƒ ƒ ƒ

The GUI package cont ains various accessors, represent ed by t he icon, and represent ers, sym bolized by t he icon: Account _ Cr e a t or D R. Represent er represent ing a GUI t hat enables t he client t o ent er t he account num ber of t he account t o be creat ed Account _ Edit or D A. Accessor cont rolling t he edit int eract ion wit h an account Account _ Edit or D R. Represent er represent ing a GUI t hat enables t he client t o m anipulat e an account Account _ SEdit or D A. Accessor t hat cont rols t he m anipulat ion of a collect ion of account s

-260-

Convergent Architecture

ƒ

Chapter 8: Tutorial Example

Account _ SEdit or D R. Represent er represent ing a GUI t o display a collect ion of account s and enable client s t o t rigger act ivit ies t o m anipulat e account s An accessor com ponent is a UML class wit h t he st ereot ype Acce ssor ( see t he bonus chapt er on t he Web sit e for det ail on m odeling st yle) . I t represent s t he flow cont rol of a user int erface. Accessors can have at t ribut es t o st ore inform at ion processed wit hin t he accessor. A represent er com ponent , a subunit of an accessor, is also a UML class wit h t he st ereot ype Re pr e se nt e r . I t is used t o display inform at ion t o t he client and t o receive input from t he client . Represent ers can have at t ribut es t o st ore t he inform at ion displayed t o or received from t he client .

Th e Ge n e r a t e d Acce ssor St a t e M ode l

TE

AM FL Y

Observing t he newly generat ed default accessors, t he m ain accessor is t he Account _ SEdit or D A. I t cont rols t he ent ire user int erface. The flow cont rol of an accessor is m odeled in a st at e/ act ivit y diagram t hat also has been generat ed aut om at ically. Figure 8.21 shows t he st at e/ act ivit y diagram for t he Account _ SEdit or D A accessor.

ƒ

Figur e 8 .2 1 : St at e/ act ivit y diagram of t he Account _SEdit orDA accessor. The cent ral elem ent in t he Account _ SEdit or D A's st at e/ act ivit y diagram is t he Edit Account S represent er st at e. This st at e is associat ed wit h t he Account _ SEdit or D R represent er. The Accou nt _ SEdit or D R represent s a GUI t hat displays all exist ing account s and provides t rigger elem ent s t o t rigger t ransit ions in t he accessor's st at e m odel. As indicat ed in t he m odel, t he client can t rigger t he following t ransit ions: Cr e a t e a n e w a ccou n t . The Account _ SEdit or D A accessor t ransit ions t o t he cr e at e Account represent er st at e. This st at e is associat ed wit h t he Account _ Cr e a t or D R represent er. The Accou n t _ Cr e a t or D R represent s a

-261-

Team-Fly®

Convergent Architecture

ƒ

ƒ

Chapter 8: Tutorial Example

GUI t hat enables t he client t o input t he account num ber for t he new account . From t he cre a t e Account represent er st at e t he accessor eit her t ransit ions back t o t he Edit Accou nt S represent er st at e, or it t ransit ions t o t he a dd act ivit y. This act ivit y is responsible for creat ing a new Accou nt com ponent wit h t he account num ber provided by t he client . From t he a dd act ivit y t he accessor t ransit ions t o t he Account _ Edit or st at e. Edit a n a ccount . The Account _ SEdit or D A accessor t ransit ions t o t he Account _ Edit or st at e. This is an em bedded accessor st at e associat ed wit h t he Accoun t _ Edit or D A accessor. I n t his st at e t he m ain accessor, Account _ SEdit or D A, delegat es t he cont rol t o t he em bedded accessor, Account _ Edit or D A. This accessor cont rols t he edit int eract ion for a single account . I t provides a represent er, Account _ Edit or D R, t hat is a GUI where t he client can edit t he balance of t he select ed account . For det ails, t ake a look at t he corresponding st at e/ act ivit y diagram of t he Account _ Edit or D A accessor com ponent . From t he Account _ Edit or st at e t he accessor t ransit ions back t o t he Edit Accou nt S represent er st at e. Two t ransit ions are provided: Ca nce lle d and Edit e d. Which one is used depends on t he end st at e of t he em bedded accessor, Account _ Edit or D A. D e le t e a n a ccount . The Account _ SEdit or D A accessor t ransit ions t o t he de le t e act ivit y. This act ivit y is responsible for delet ing t he select ed Account com ponent . From t he de le t e act ivit y t he accessor t ransit ions back t o t he Edit Account S represent er st at e. A represent er st at e m ust be associat ed wit h a specific represent er, and an em bedded accessor st at e m ust be associat ed wit h an specific accessor. This is done in t he Re pr e se nt e r St a t e 's or Em be dde dAcce ssor St a t e 's Ar cSt yle r specificat ion dialog. Figure 8.22 shows t he dialog for t he Edit Accou nt S represent er st at e.

Figur e 8 .2 2 : St at e specificat ion dialog.

-262-

Convergent Architecture

Chapter 8: Tutorial Example

I n t he lower part of t he st at e's propert y sheet you can specify t he resource m apping for t he st at e. This m aps t he at t ribut es of t he associat ed represent er or em bedded accessor in t he left panel, Pr ope r t ie s, t o t he respect ive at t ribut es of t he cont rolling accessor ( in our exam ple t his is t he Account _ SEdit or D A accessor) shown in t he right panel. The resource m apping defines t he dat a flow in t he m odel. A resource m apping causes t he at t ribut e of t he represent er or em bedded accessor t o be init ialized wit h t he current value of t he associat ed at t ribut e of t he cont rolling accessor.

M ode lin g Re pr e se n t e r s Represent ers are det ailed using t he represent er's ArcSt yler specificat ion dialog. Figure 8.23 shows t he dialog of t he Account _ SEdit or D R represent er.

Figur e 8 .2 3 : Represent er specificat ion dialog. At t he t op of t he dialog you can specify t he Re pr e se nt e r t ype : COLLECTI ON , which specifies t hat t he represent er w ill display a collect ion of inst ances ( for exam ple, t he Account _ SEdit or D R represent er) , or SLI CE, w hich m eans t hat t he represent ers will display exact ly one inst ance ( for exam ple, t he Account _ Cr e a t or D R represent er) . I n t he left panel you can m odel t he I nt e r a ct ion At t r ibu t e s and Eve nt s provided by t he represent er. I nt eract ion at t ribut es represent edit fields or t ext fields in t he represent er ( for exam ple, edit fields in a JSP) . Event s represent but t ons in t he user int erface t hat t rigger corresponding t ransit ions in t he st at e m achine of t he cont rolling accessor.

-263-

Convergent Architecture

Chapter 8: Tutorial Example

I n t he low er right part of t he represent er's specificat ion dialog you can specify t he resource m apping bet w een an int eract ion at t ribut e and t he associat ed represent er at t ribut e t o be displayed in t he int eract ion at t ribut e's t ext or edit field. Figure 8.23 em phasizes t he resource m apping bet ween t he I nt e r a ct ion At t r ibut e , a ccount N um be r , and t he a ccount N um be r at t ribut e of t he represent er's a ccount S at t ribut e. Ex t e nding t he D e fa ult Acce ssor M ode l I n t his sect ion you will st art from default accessor m odel t o creat e your own cust om ized accessor. You will add an act ivit y, init , t o t he st at e/ act ivit y diagram of t he m ain accessor, Account _ SEdit or D A. This act ivit y will be responsible for finding all exist ing account s and init ializing t he a ccount S at t ribut e of t he Account _ SEdit or D A accessor wit h t he found collect ion of account s. Proceed as follows: Add a new act ivit y, init . Redirect t he a ct iva t e t ransit ion from t he St a r t st at e t o t he init act ivit y by dragging t he t ransit ion arrow. 3. Add a new t ransit ion from t he init act ivit y t o t he Edit Account S represent er st at e. Figure 8.24 shows t he com plet ed diagram for t he cust om ized accessor.

1. 2.

Figur e 8 .2 4 : Modified st at e/ act ivit y diagram

-264-

Convergent Architecture

Chapter 8: Tutorial Example

M ode lin g t he W e b App D e ploym e nt Com pone nt Now you will ext end t he assem bly m odel in t erm s of t he accessor's deployable com ponent s for t he Web applicat ion. You will m odel t he a Web applicat ion archive ( WAR) t hat packages t he accessor and represent er com ponent s of t he m odel for aut om at ic deploym ent int o a Web server. To m odel t he Web applicat ion archive, proceed as follow s: Add a new com ponent , w e ba pp, wit h t he st ereot ype W e ba pplica t ion t o t he libs package you creat ed earlier for t he business com ponent s. 2. I n t he w e ba pp com ponent 's ArcSt yler specificat ion dialog, specify t he Account _ SEdit or D A accessor as root accessor t hat t akes t he m ain cont rol. Figure 8.25 shows t he result . 1.

Figur e 8 .2 5 : Assigning t he root accessor. I n order t o guarant ee a com plet e assem bly for t he deployed environm ent , t he deploym ent dependencies bet ween t he packaged Web accessor com ponent s and t he packaged business com ponent s is also m odeled. I n t he UML m odel, t his is expressed by adding a dependency relat ion bet w een t he Web applicat ion com ponent and t he EJB client archive com ponent , st ubs. To m odel t his dependency, proceed as follow s: 1. Add a com ponent diagram , D e pe nde ncie s, t o t he libs package. 2. Drag and drop t he st ubs and w e ba pp com ponent s from t he Rose browser int o t he diagram and insert a dependency from t he w e ba pp com ponent ( client com ponent ) t o t he st ubs com ponent ( server com ponent ) . Figure 8.26 shows t he D e pe nde n cie s diagram .

-265-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .2 6 : The Dependencies diagram . At t his point , you have a refined t he UML m odel of your accessor com ponent s and assem bly com ponent s t o t he level w here t he C- GEN generat or and t echnology proj ect ion cart ridge can t ake over and generat e a deployable infrast ruct ure.

Ge ne r a t in g t h e W e b Applica t ion w it h C- GEN This sect ion covers t he code- generat ion st eps for t he Web accessors. The archit ect ural I DE is now used t o support t hese accessor- specific aspect s of t he CA process work flows. I n t his st ep, t he C- GEN m odule and accessor t echnology proj ect ion cart ridge are act ivat ed from t he C- REF UML m odel. These are used t o generat e m aj or port ions of t he deploym ent infrast ruct ure as well as t he t est and build environm ent for t he JSP/ servlet - based Web applicat ion. Configur in g t he Code Ge ne r a t or Before you st art generat ing accessor code, you m ust configure t he code generat or using t he ArcSt yler configurat ion dialog.

Th e Ge n e r a t e Pa n e l ƒ ƒ ƒ

I n t he Ge ne r a t e panel, you m ust specify t he following: Ge ne r a t e d Sour ce D ir e ct or y. This specifies t he source- code out put direct ory. Te m pla t e D ir e ct or y. This specifies t he pat h where t he code generat or searches for t he t em plat es. Pr oj e ct N a m e . This specifies t he nam e of t he proj ect , for exam ple, iBa nk Tut or ia l.

-266-

Convergent Architecture

Chapter 8: Tutorial Example

Figure 8.27 shows t he com plet ed configurat ion of t he Ge ne r a t e panel.

Figur e 8 .2 7 : The Generat e panel.

Th e Pr oj e ct ions Pa n e l ƒ ƒ ƒ

I n t he Pr oj e ct ions panel, you m ust specify t he t echnology proj ect ion cart ridges needed for accessor code generat ion. Add t he following proj ect ion.t pr files in t he Ch ose n Te chnology Pr oj e ct ions field: proj ect ion.t pr file corresponding t o your t arget EJB cont ainer. You should have done t his already in a previous sect ion of t he sam ple. iO_ JSP_ a cce ssor s.t pr file corresponding t o t he JSP/ servlet cart ridge. For t his cart ridge, you also m ust configure t he JBuilder version inst alled in your local environm ent . Figure 8.28 shows t he Pr oj e ct ions panel configured wit h t he accessor cart ridge as well as t he Borland Applicat ion Server cart ridge and JBuilder4.

-267-

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .2 8 : The Proj ect ions panel. You have now configured t he code generat or. Save t he configurat ion. Run nin g t he Code Ge ne r a t or By default , t he C- GEN generat es code for all t echnology proj ect ions configured in t he Pr oj e ct ions panel. However, because t he EJB business com ponent s were already generat ed in previous sect ions, we only need t o generat e t he code for t he Web accessors here. To do so, select t he ent ire Logica l V ie w package in t he CREF/ Rose browser and use it s Ar cSt yle r → Con figur e Generat ion cont ext m enu. The select or dialog shown in Figure 8.29 pops up where you should select only t he JSP/ servlet cart ridge.

-268-

Convergent Architecture

ƒ ƒ ƒ ƒ ƒ ƒ

Chapter 8: Tutorial Example

Figur e 8 .2 9 : The cart ridge select or dialog. Now you can run t he code generat or. I n t he C- REF/ Rose browser, select t he Logica l V ie w , and use it s Ar cSt yle r → Ge ne r a t e cont ext m enu in order t o generat e all art ifact s for t he Web accessor infrast ruct ure. I n t his inst ance, t he generat ed infrast ruct ure includes t he following: Java sources for t he accessor and represent er com ponent s. The Java sources are generat ed in t he % SRC% / ui_ j sp_ ge n/ j a va / iba nk / GUI direct ory, w here % SRC% is t he source- code out put direct ory you configured in t he Ge ne r a t e panel. JSP sources for t he represent er com ponent s. The JSP sources are generat ed in t he % SRC% / ui_ j sp_ ge n/ sit e / iba nk / GUI direct ory. Web applicat ion build support files. The cont ainer- specific build support files are generat ed in t he % SRC% / com pone nt s/ libs/ w e ba pp/ ui_ j sp direct ory. Progress and inform at ion pert aining t o t he code generat ion are logged t o t he Rose log window, as shown in t he Figure 8.30.

Figur e 8 .3 0 : Rose log window.

-269-

Convergent Architecture

Chapter 8: Tutorial Example

Bu ildin g, D e ployin g, a n d Te st in g t h e W e b Applica t ion This sect ion shows how t o use one of several build, deploy, and t est const ellat ions for Web accessors. I t exhibit s t he archit ect ural I DE support for accessor aspect s of t he im plem ent at ion cycle work flows, t est work flow s, and deploym ent and m onit oring work flow. ƒ ƒ ƒ ƒ

Once t he infrast ruct ure has been generat ed, t he following t asks are at hand: Cust om ize code. Build t he Web applicat ion WAR file. Deploy t he WAR file in a Web server. Test t he Web applicat ion in an I nt ernet browser.

ƒ ƒ ƒ

This sect ion cont ains t he following subsect ions: Code cust om izat ion Build support Running t he Web applicat ion Code Cust om iza t ion I n t his sect ion you will im plem ent t he init act ivit y m et hods m odeled in t he st at e/ act ivit y diagram of t he Account _ SEdit or D A accessor. Moreover, you will cust om ize som e propert ies in t he w e b.x m l file generat ed for t he Web applicat ion. You can use any edit or t o cust om ize t he source code. How ever, Borland's Java I DE is explicit ly support ed by t he archit ect ural I DE for t his purpose. A JBuilder proj ect file, w e ba pp.j px , w as generat ed in t he % SRC% / com pone nt s/ libs/ w e ba pp/ ui_ j sp direct ory. I t cont ains t he Java sources, t he JSP sources, t he w e b.x m l file, a la unch.ht m l file t o t est t he Web applicat ion in an I nt ernet brow ser, and ot her JBuilder- specific configurat ion inform at ion.

Th e Accou n t _ SEdit or D A.j a va File The Account _ SEdit or D A.j a va file was generat ed int o t he % SRC% / ui_ j sp_ ge n/ j a va / iba nk / GUI direct ory. I n t his file you m ust com plet e t he generat ed doI nit ( ) m et hod for t he init act ivit y. The following code fragm ent shows t he im plem ent at ion of t he doI nit ( ) m et hod: j ava.ut il.Collect ion col = get Account Hom e( ) .findAllI nst ances( ) ; j ava.ut il.I t erat or it = col.it erat or( ) ; m _Account S = new ibank.Account [ col.size( ) ] ; int i= 0; while( it .hasNext ( ) ) { ibank.Account acc = ( ibank.Account ) j avax.rm i.Port ableRem ot eObj ect .narrow( it .next ( ) ,ibank.Account .class) ; Syst em .out .print ln( " Account " + acc.get Account Num ber( ) ) ; m _Account S[ i+ + ] = acc; }

-270-

Convergent Architecture

Chapter 8: Tutorial Example

Build Suppor t The ArcSt yler provides ext ensive support for building, deploying, and t est ing Web applicat ions. I n t his sect ion you will com plet e t hese t asks using bot h ANT- based com m and- line support and, opt ionally, t he JBuilder Java I DE support .

AN T- Ba se d Bu ild Su ppor t The C- GEN m odule generat es ANT script s in t he % SRC% / com pone nt s/ libs/ w e ba pp/ ui_ j sp direct ory. The build process is configured in t he j sp.x m l file. The Java propert ies needed for t he build process are defined in t he pr oj e ct .pr ope r t ie s file. Bot h files cont ain prot ect ed areas so t hat t he build process can be cust om ized at any t im e.

I n general, t he build process is highly cont ainer- specific. For det ails, please refer t he respect ive accessor cart ridge docum ent at ion. One such cart ridge docum ent is present ed in t he bonus chapt er on t he Web sit e, which covers t he det ails of t he t echnology proj ect ion com ponent in reference m anual form . Ot her cart ridge docum ent at ion are also available via t he Convergent Archit ect ure Web sit e.

AM FL Y

ƒ

I D E- Ba se d Bu ild Su ppor t

I n t he previous st eps, build support for Borland's Java I DE JBuilder also w as generat ed aut om at ically. The respect ive JBuilder proj ect files, libraries, and configurat ions were generat ed int o t he % SRC% / com pone nt s/ libs/ w e ba pp/ ui_ j sp direct ory.

TE

ƒ

Now act ivat e t he following build t arget s. These are t he crit ical- pat h subset of t he available build t arget s. build. This com piles t he JSP and Java sources and generat es t he WAR file, w e ba pp.w a r . The WAR file is st ored in t he % SRC% / com pone nt s/ libs direct ory. build st a r t Tom ca t . This st art s t he Tom cat servlet engine.

The advant age of Java I DE- based build support is t hat you can use t he I DE for visual debugging and t est ing. For det ails, please refer t he respect ive accessor cart ridge docum ent at ion. Run nin g t he W e b Applica t ion Before you run t he Web applicat ion, m ake sure t hat business com ponent s are deployed in t he running EJB cont ainer and t hat t he Tom cat servlet engine has been st art ed as described previously. Now st art your favorit e I nt ernet browser by act ivat ing t he la unch.ht m l file t hat was generat ed in t he % SRC% / com pone nt s/ libs/ w e ba pp/ ui_ j sp direct ory. This will run t he Web applicat ion. Figure 8.31 show s one of t he int errelat ed accessor GUI s you developed earlier. This accessor GUI was generat ed from t he Account _ SEdit or D R represent er.

-271-

Team-Fly®

Convergent Architecture

Chapter 8: Tutorial Example

Figur e 8 .3 1 : The running Web applicat ion.

Su m m a r y The iBank t ut orial present ed in t his chapt er has led you sequent ially t hrough m any cent ral aspect s of t he CA process and it s com m ensurat e support in t he archit ect ural I DE. The t ut orial st art ed you off wit h convergent business m odeling and m oved you t hrough t he st ages of convergent UML refinem ent st ages t o arrive at an assem bly of deployable J2EE/ EJB business com ponent s. You t hen learned how t o generat e and refine Web accessor m odels and how t o generat e t he ent ire J2EE/ EJB infrast ruct ure from t he UML m odel. Last ly, you saw how t o build, deploy, and t est bot h t he EJB business com ponent and t he Web accessors using t he generat ed infrast ruct ure. For addit ional t ut orials and sam ples, refer t o t he Convergent Archit ect ure Web sit e: www .Convergent Archit ect ure.com .

-272-

Convergent Architecture

Bibliography

Bibliogr a ph y Book s Alexander, C. 1975. The Oregon Experim ent . New York: Oxford Universit y Press. I SBN 0- 19- 501824- 9.

Alexander, C., et . al. 1977. A Pat t ern Language: Towns, Buildings, Const ruct ion. New York: Oxford Universit y Press. I SBN 0- 19- 501919- 9. Coplein, J. 1992. Advanced C+ + Program m ing St yles and I diom s. Reading, MA: Addison- Wesley. I SBN 0- 201- 54855- 0. Coplien, J., Schm idt , D., eds. 1995. Pat t ern Languages of Program Design. Reading, MA: Addison- Wesley. I SBN 0- 201- 60734- 4. Drost e, M. 1998. Bauhaus 1919–1933. Berlin: Bauhaus- Archiv Museum fuer Gest alt ung, Klingelhoeferst r. I SBN 3- 8228- 7601- 1. D'Souza, D. 1998. Obj ect s, Com ponent s, and Fram eworks w it h UML: The Cat alysis Approach. Reading, MA: Addison- Wesley. I SBN 0- 201- 31012- 0. Gilb, T. 1988/ 1999. Principles of Soft ware Engineering Managem ent . Reading, MA: Addison- Wesley. EPM99- EPM: Evolut ionary Proj ect Managem ent : w w w .na t ur a lm e t r ics.fr e e se r ve .co.uk / dow nloa d.ht m . Graham , I ., Henderson- Sellers B., Younessi H. 1997. The OPEN Process Specificat ion. Reading, MA: Addison- Wesley Longm an. I SBN 0- 201- 33133- 0. Henderson- Sellers, B., Sim ons, Y. 1998. The OPEN Toolbox of Techniques. Reading, MA: Addison- Wesley. I SBN 0- 201- 33134- 9. Herrm ann, W., ed. 1992. I n What St yle Should We Build? The Germ an Debat e on Archit ect ural St yle. Sant a Monica, CA: Get t y Cent er for t he Hist ory of Art and t he Hum anit ies. I SBN 0- 89236- 199- 9. Heyer, P. 1993. Archit ect s on Archit ect ure: New Direct ions in Am erica. New York: Van Nost rand Reinhold. I SBN 0- 442- 01751- 0. Hofst adt er, D. 1979. Goedel Escher Bach. New York: Vint age Press. I SBN 0- 39475682- 7 Kane, G. 1988. Mips RI SC Archit ect ure. Englewood Cliffs, NJ: Prent ice- Hall. I SBN: 013- 584749- 4. Krucht en, P. 1998. The Rat ional Unified Process. Reading, MA: Addison- Wesley Longm an. I SBN 0- 201- 60459- 0.

-273-

Convergent Architecture

Bibliography

Taylor, D. A. 1995. Business Engineering w it h Obj ect Technology. New York: John Wiley & Sons. I SBN: 0- 471- 04521- 7. Taylor, D. A. 1997. Obj ect Technology: A Managers Guide, 2d ed. Reading MA: Addison- Wesley. I SBN 0- 201- 30994- 7. Warm er, J. 1999. The Obj ect Const raint Language: Precise Modeling wit h UML. Reading, MA: Addison- Wesley Longm an. I SBN 0- 201- 37940- 6.

Pa pe r s a n d Ar t icle s Aalst , V. 1998. " Form alizat ion and Verificat ion of Event - Driven Process Chains." Com put ing Science Report s, 98/ 01; cit eseer.nj .nec.com / 208211.ht m l.

Am bler, S. 1997. " Archit ect ure Driven Modeling: The 'T' Approach." Microsoft MSDN Online; m sdn.m icrosoft .com / library/ periodic/ period97/ Modeling.ht m . Girouard, M. 1963. " Mont icello, Virginia, The Hom e of Thom as Jefferson from 1771 t o 1826." Count ry Life, 133 ( January 17, 1963) : 108. I ggulden, D., Rees, O., Van der Linden, R. 1994. " Archit ect ure and Fram eworks: Advanced Net work Syst em Archit ect ure Phase I I I ( ANSA Phase I I I ) ." APM.1017.02, Oct ober 25, 1994; www.ansa.co.uk. Krucht en, P. 2000. " Developing Large Scale Syst em s wit h t he Rat ional Unified Process." RUP 2000, t echnical whit e paper; www .rat ional.com / product s/ whit epapers/ sis.j sp. Lewis, T. 1999. " Where t he Sm art Money I s?" I EEE Com put er, Novem ber 1999: 136; com put er.org. Oberg, R. 2000, " Applying Requirem ent s Managem ent wit h Use- Cases." RUP 2000, t echnical whit e paper TP505; www.rat ional.com / product s/ whit epapers/ 100622.j sp.

St a n da r ds ( RFCs, I TU Re com m e n da t ions, e t c.) EJB. 2001. The Ent erprise Java Beans specificat ions m ay be found at j ava.sun.com / product s/ ej b.

I EEE. 2000. " Archit ect ural Descript ion of Soft ware I nt ensive Syst em s." I EEE St andard 1471–2000, I EEE Com put er Societ y; www.ieee.org. J2EE Blueprint s. 2001. Available from j ava.sun.com / j 2ee/ blueprint s. J2EE Pat t erns. 2001. Available t o m em bers of t he Java Developer's Connect ion t hrough developer.j ava.sun.com / developer/ rest rict ed/ pat t erns/ J2EEPat t ernsAt AGlance.ht m l.

-274-

Convergent Architecture

Bibliography

J2EE. 2001. The Java 2 Ent erprise Environm ent specificat ions m ay be found at j ava.sun.com / j 2ee. JCP. 2001. The Java Com m unit y Process. Available at j ava.sun.com / about Java/ com m unit yprocess. MDA. 2001. " OMG Model- Driven Archit ect ure I nit iat ive." Available at www .om g.com / m da. UML. 2000. " The OMG Unified Modeling Language Specificat ion." Version 1.3, March 2000. Available at w ww.om g.org/ cgi- bin/ doc?form al/ 2000- 03- 01.

Tools ANT. 2000. The Apache Jakart a Proj ect . Available at j akart a.apache.org/ ant / index.ht m l, j akart a.apache.org/ ant / m anual/ index.ht m l.

BEA Syst em s Corporat ion. 2001. The WebLogic Server. Available at www .beasys.com . Borland Corporat ion. 2001. The Borland Applicat ion Server. Available at www .borland.com . iO Gm bH. 2001. I nt eract ive Obj ect s Soft ware Gm bH. The ArcSt yler Archit ect ural I DE for J2EE/ EJB. Available at www.ArcSt yler.com , www.io- soft ware.com . JUnit . 2000. Available at www.j unit .org/ . Rat ional Corporat ion. 2000. The Rat ional Unified Process. Rat ional Corporat ion. 2001. Rat ional Rose 2001 Modeler Edit ion. Available at www .rat ional.com .

-275-

Convergent Architecture

Index

I nde x A ABD ( analysis by design) , 38, 172–177 accessors, 40, 78, 92 cont ainer, 96 fram ework, 93–94 Account _SEdit orDA accessor, iBank t ut orial, 250–251 Account Bean.j ava file, iBank t ut orial, 243 Account _SEdit orDA.j ava file, iBank t ut orial, 260 Account _SEdit orDR represent er, iBank t ut orial, 252 act ivit ies, 113 accessors, 98 owner, 116 allocat e and est im at e phase, four- pass it erat ion planning session, 162 ANT script s, iBank t ut orial, 247 applied archit ect ures, 7 archit ect ural evolut ion workflows, 158–159 archit ect ural I DE, 38–41, 193–195 C- BOM m odule, 196–197 C- GEN m odule, 209 C- GEN- I DE m odule, 211–213 C- I X m odule, 213–216 C- RAS m odule, 200–201 C- REF m odule, 203–207 Federat ed UML/ XML m odel reposit ory, 199 archit ect ural layers, convergent com ponent m et am odel, 76–81 archit ect ural st yles. See I T archit ect ural st yle. archit ect ure organizat ion, I T organizat ion, 118–120 ArcSt yler proj ect s, iBank t ut orial, 222 art ifact s, 113, 171 assem blies, 77, 91 assem bly developm ent t eam , 133, 137–138, 165 assem bly t est s, 184

B build process, iBank t ut orial, 260–261 build, t est and deploy const ellat ions, iBank t ut orial, 242 business and requirem ent s m odeling, 48 business com ponent s, 78, 99–102 business flow and convergence t est ing, 185 business m odel packages, iBank t ut orial, 220–222 business use- case scenarios, iBank t ut orial, 223–224 business- relevant assem bly com ponent s, 132

C C- BOM m odule ( Convergent Business Obj ect Modeler) , 38, 196–197, 220 C- GEN m odule ( Convergent Translat ive Generat or) , 40, 209, 238–240 C- GEN- I DE m odule ( Convergent Generat or I DE) , 41, 211–213 C- I X m odule ( Convergent I m plem ent , Deploy and Test Environm ent ) , 41, 213–216 C- RAS m odule ( Convergent Pat t ern Refinem ent Assist ant ) , 39, 200–201, 227

-276-

Convergent Architecture

C- REF m odule ( Convergent UML Refinem ent Assist ant ) , 40, 203–207, 232 canonical developm ent t eam , 133–135 canonical proj ect workflows, 150–151 cat alysis approach, 148 CC- encapsulat ed t echnologies, 44 CCM workflow ( Configurat ion and Change Managem ent ) , 169–171 CCM- O ( Change and Configurat ion Managem ent organizat ion) , 123–124 CCs ( Convergent Com ponent s) , 76 change set s, 113 client personalit ies, convergent com ponent m et am odel, 87–88 code cust om izat ion, iBank t ut orial, 242 code generat or, iBank t ut orial, 238, 241 com ponent developm ent t eam s, 133, 139–140 com ponent s dim ensions, convergent com ponent m et am odel, 85–87 m et am orphosis, 36, 68–70 t est s, 184 concept ual isom orphism , 36, 65–67 const ruct ion phase, RUP, 166 convergence, 59 convergent archit ect ure, 1, 11–14 archit ect ural I DE, 193–195 C- BOM m odule, 196–197 C- GEN m odule, 209 C- GEN- I DE m odule, 211, 213 C- I X m odule, 213–214, 216 C- RAS m odule, 200–201 C- REF m odule, 203–207 Federat ed UML/ XML m odel reposit ory, 199 com m unicat ion, 5 convergent com ponent m et am odel. See convergent com ponent m et am odel. designer's paradox, 26–27 developm ent process m odel, 145–147 ABD w orkflows, 172–177 archit ect ural evolut ion workflows, 158–159 assem bly developm ent t eam , 165 canonical proj ect workflows, 150–151 CCM workflows, 169–171 const ruct ion phase, 166 cross- proj ect workflows, 149 deploym ent workflows, 188–189 developm ent environm ent workflows, 167–169 docum ent at ion workflows, 185–187 im plem ent at ion cycle workflow s, 179–181 I T environm ent workflows, 152 m onit oring workflow s, 188–189 preparat ory workflows, 149 proj ect init iat ion t eam , 164 proj ect m anagem ent workflows, 159–163 refinem ent cont inuit y, 178–179 T- bar workflows, 153–158 t est w orkflows, 182–184 t ransit ion phase, 166

-277-

Index

Convergent Architecture

workflows, 148–149 ent ropy, 25–26 evolut ion, 9 form al t echnology proj ect ions, 21–23 full coverage t ool suit e, 20 full lifecycle developm ent m odel, 18–19 iBank t ut orial. See iBank t ut orial. I T organizat ion m odel, 109–112, 118–120 CCM- O, 123–124 I T support organizat ion, 121–122 I T- O, 116 OPS- I nfraBas- O, 143 OPS- O, 141 PET- O, 125–126 SysDev- O, 129–132, 135–139 Test Cent er- O, 127–128 Transit ion- O, 142 UserSupport - O, 142 m et am odels, 16–17 organic order, 27 qualit y, 8 specificit y, 24–25 st andards, 28 unnecessary com plexit y, 15 convergent archit ect ure m et am odel, 53 com ponent m et am orphosis, 68–70 concept ual isom orphism , 65–67 m achine shop m et aphor, 62 proj ect design, 57 RASC, 63–64 syst em design, 58 convergent archit ect ure roadm ap, 31–33 archit ect ural I DE, 38–41 cum ulat ive im provem ent s sum m ary, 47–48, 50 developm ent m odel, 36 m et am odels, 34–36 operat ional environm ent , 44, 46 t echnology proj ect ions, 42–44 convergent com ponent m et am odel, 36, 73–74 accessors, 92–96 archit ect ural layers, 76–81 assem blies, 91 client personalit ies, 87–88 com ponent dim ensions, 85, 87 ext ended st at e m achine m odel, 97–98 m odel- driven accessors, 94–95 MVC cont roller, 95 OPRs, 99, 103 represent ers, 96–97 ResourceMappings, 98 server personalit ies, 87–88 TPC, 83–85 ut ilit y com ponent s, 107

-278-

Index

Convergent Architecture

convergent engineering, 59–61 convergent syst em s, 60 convergent UML com plet ions, 176 convergent UML represent at ions, 175 CRC cards ( class responsibilit y cards) , 38, 223 cross proj ect workflows, 149 cum ulat ive im provem ent s sum m ary, 47–50 cust om izing accessor, iBank t ut orial, 253

D Dat abase panel, iBank t ut orial, 239 decisions, accessors, 98 default accessors, iBank t ut orial, 249 deploym ent workflow, 188–189 design, 12–14 designer's paradox, 26–27 developm ent environm ent workflow, 167, 169 developm ent m odels, 36 developm ent process m odel, 37, 145–147 ABD w orkflow, 172–177 archit ect ural evolut ion workflows, 158–159 assem bly developm ent t eam , 165 canonical proj ect workflows, 150–151 CCM workflow, 169–171 const ruct ion phase, 166 cross- proj ect workflows, 149 deploym ent workflow, 188–189 developm ent environm ent workflow, 167, 169 docum ent at ion workflow, 185–187 im plem ent at ion cycle workflow, 179–181 I T environm ent workflows, 152 m onit oring workflow , 188–189 preparat ory workflows, 149 proj ect init iat ion t eam , 164 proj ect m anagem ent workflows, 159–163 refinem ent cont inuit y, 178–179 T- bar workflows, 153–158 t est w orkflow, 182–184 t ransit ion phase, 166 workflows, 148–149 developm ent t ool environm ent , 50 divergence, 59 docum ent at ion, 50 docum ent at ion workflow, 185–187

E EAI ( Ent erprise Applicat ion I nt egrat ion) , 26 EARs ( Ent erprise archives) , 81 elaborat ion phase, RUP, 165 Em beddedAccessorSt at e, 97 ent ropy, 25–26 EPM ( Evolut ionary Proj ect Managem ent ) , 148

-279-

Index

Convergent Architecture

ext ended st at e m achine m odel, 97–98 ext ernal ent it ies, 92

F federat ed UML/ XML m odel reposit ory, 199 form al t echnology proj ect ions, 21–23 four- pass it erat ion planning sessions, 162–163 full- coverage t ool suit e, 20 full lifecycle developm ent m odel, 18–19

G– H Generat e panel, iBank t ut orial, 238 holist ic approach t o archit ect ure design, 54–56

I iBank t ut orial, 219 Account Bean.j ava file, 243 Account _SEdit orDA. j ava file, 260 ANT script s, 247 ArcSt yler proj ect , 222 build process, 260–261 build, t est and deploy const ellat ions, 242 business m odel packages, 222 business use- case scenarios, 223–224 C- BOM business m odeling, 220 C- GEN m odule configuring code generat or, 238 Dat abase panel, 239 Generat e panel, 238 generat ing EJB com ponent s, 238 Proj ect ions panel, 239 running code generat or, 241 Tools panel, 240 C- RAS m odule, 227 C- REF m odule, 232 Acconut _SEdit orDA accessor, 250–251 Account _SEdit orDR represent er, 252 cust om izing accessor, 253 default accessors, 249 Web accessors, 248 code cust om izat ion, 242 CRC cards, 223 im port ing reposit ory, 233 m odel docum ent at ion, 226 m odel verificat ion, 225, 230, 237 m odel.j ar archive, 246 m odeling account com ponent , 233–234 m odeling deployable com ponent , 237 m odeling t ransfer com ponent , 236 m odelTest Client .j ava file, 244–245 refining account business obj ect responsibilit ies, 228

-280-

Index

Convergent Architecture

Index

TE

AM FL Y

refining business obj ect responsibilit ies, 227 refining t ransfer business obj ect responsibilit ies, 230 running code generat or, 257–258 st ubs.j ar archive, 247 TransferBean.j ava file, 244 Web applicat ion deploym ent com ponent , 254 Web applicat ion generat ion, 255–257 web.xm l file cust om izat ion, 260 I DE ( I nt egrat ed Developm ent Environm ent ) , 193 im plem ent , build and deploy cycle, 49 im plem ent at ion cycle workflow, 179–181 im plicit qualit y, 49 im port ing reposit ory, iBank t ut orial, 233 incept ion phase, RUP, 164 init iat ion t eam , 164 innovat ion wit hout risk, 10 I OC ( I nit ial Operat ional Capabilit y) , RUP, 166 I T archit ect ural st yle, 1, 11 com m on language, 6 com m unicat ion, 5 design, 12–14 designer's paradox, 26–27 ent ropy, 25–26 evolut ion, 9 form al t echnology proj ect ions, 21–23 full- coverage t ool suit e, 20 full lifecycle developm ent m odel, 18–19 m et am odels, 16–17 organizat ional evolut ion, 28 qualit y cont rols, 8 specificit y, 24–25 st andards, 28 unnecessary com plexit y, 15 I T dim ensions, 86 I T environm ent workflows, 152 I T- organizat ion developm ent m odel, 36 I T- organizat ion m odel, 109–112, 118–120 CCM- O, 123–124 I T support organizat ion, 121–122 I T- O, 116 OPS- I nfraBas- O, 143 OPS- O, 141 PET- O, 125–126 SysDev- O, 129–132, 135–139 Test Cent er- O, 127–128 Transit ion- O, 142 UserSupport - O, 142 I T support organizat ion, 121–122 I T- O ( I T organizat ion) , 116

J– L Jum pSt at e, 98

-281-

Team-Fly®

Convergent Architecture

LCO ( Life- Cycle Obj ect ive) , RUP, 165

M m achine shop m et aphor, 61 m et am odels, 16–17, 34–36, 53 business design, 57 com ponent m et am orphosis, 68–70 concept ual isom orphism , 65–67 convergent com ponent . See convergent com ponent m et am odel. holist ic approach, 54–56 m achine shop m et aphor, 62 proj ect design, 57 RASC, 63–64 syst em design, 58 m odel docum ent at ion, iBank t ut orial, 226 m odel verificat ion, iBank t ut orial, 225, 230, 237 m odel- driven accessors, 94–95 m odel- driven design, 75 m odel.j ar archive, iBank t ut orial, 246 m odeling account com ponent , iBank t ut orial, 233–234 m odeling deployable com ponent , iBank t ut orial, 237 m odeling t ransfer com ponent , iBank t ut orial, 236 ModelTest Client .j ava file, iBank t ut orial, 244–245 m onit oring workflow , 188–189 MVC cont roller, 95

O official sink, 157 OPEN Process Specificat ion, 147 operat ional environm ent , 44–46 operat ional increm ent s, 166 OPRs ( organizat ions, processes, and resources) business com ponent s, 79, 99–102 business- cent ric, 131–132 convergent com ponent s, 103 I T organizat ion m odel, 112 t echnology proj ect ions, 104–106 UML m odeling, 104–106 OPS- I nfraBas- O, I T organizat ion, 143 OPS- O, I T organizat ion, 141 organic order, 27 organizat ion m anager, 115 organizat ions, 112

P peripheral t ools, 44 PET- O ( Proj ect I nform at ion, Event s, and Training organizat ion) , 125–126 preparat ory workflows, 149 processes, 112 proj ect design, 57 proj ect init iat ion t eam , 164

-282-

Index

Convergent Architecture

proj ect m anagem ent workflows, 159–163 proj ect m anager, 115 Proj ect ions panel, iBank t ut orial, 239

Q– R qualit y, 8 RASC ( Reduced Abst ract ion Set Com put ing) , 35, 63–64 RDD ( responsibilit y- driven design) , 38 reference art ifact s, 171 reference fram e cont inuit y, 146 reference t echnologies, 114 refinem ent cont inuit y, 178–179 refining responsibilit ies, iBank t ut orial, 227–230 represent ers, 96 represent er cont ainers, 97 Represent erSt at e, 97 resource owner, 116 ResourceMappings, 98 resources, 113 responsibilit ies of workers, 115 RI SC ( reduced inst ruct ion set com put ing) , 63 roadm ap for convergent archit ect ure, 31–33 archit ect ural I DE, 38–41 cum ulat ive im provem ent s sum m ary, 47–50 developm ent m odel, 36 m et am odels, 34–36 operat ional environm ent , 44, 46 t echnology proj ect ions, 42–44 run- t hrough, four- pass it erat ion planning session, 163 runt im e environm ent , 50 RUP ( Rat ional Unified Process) , 146–147 const ruct ion phase, 166 elaborat ion phase, 165 incept ion phase, 164 I OC ( I nit ial Operat ional Capabilit y) , 166 LCO ( Life- Cycle Obj ect ive) , 165 t ransit ion phase, 166 workflows, 148

S scenario m odels, 174 server personalit ies, convergent com ponent m et am odel, 87–88 SI - ACCs ( syst em int erface accessors) , 92 specificit y, 24–25 sponsoring client , 116 st andards, 28 st eering t eam , 116 STTs ( st at e t ransit ion t ables) , 38 St ubs.j ar archive, iBank t ut orial, 247 SysDev- O, I T organizat ion, 129–132, 135–139 syst em design, 58 syst em developm ent proj ect s, 130–131

-283-

Index

Convergent Architecture

T T- bar business analysis, 153–156 T- bar workflows, 153–158 t alk- t hrough, four- pass it erat ion planning session, 162 t echnologies ( reference) , 114 t echnology proj ect ions, 38, 42–44, 104–106 t est w orkflow, 182–184 Test Cent er- O, I T organizat ion, 127–128 t est ing, 49 TOMA ( Task Ownership Mat rix) , 161 Tools panel, iBank t ut orial, 240 TPC ( Technology Proj ect ion Com ponent ) , 83–85 TransferBean.j ava file, iBank t ut orial, 244 t ransit ion phase, RUP, 166 Transit ion- O, I T organizat ion, 142 t ut orials, iBank. See iBank t ut orial.

U ubiquit ous t echnologies, 43 UI - accessors, 46 UI - ACCs ( user int erface accessors) , 92 UI - represent ers, 46 UML ( Unified Modeling Language) , 39, 104–106 unit t est , 184 unnecessary com plexit y, 15 use- case scenario m odels, 174, 223 UserSupport - O, I T organizat ion, 142 ut ilit ies, 78, 107

W–X Walk- t hrough, four- pass it erat ion planning session, 163 WARs ( Web archives) , 81 Web accessors, iBank t ut orial, 248 Web and syst em accessor developm ent , 48 Web applicat ion deploym ent com ponent , iBank t ut orial, 254 Web applicat ion generat ion, iBank t ut orial, 255–257 Web.xm l file cust om izat ion, iBank t ut orial, 260 Workers, 113–115 Workflow owner, 116 Workflows, 113, 148–149 ABD, 172–177 archit ect ural evolut ion, 158–159 canonical proj ect , 150–151 CCM, 169–171 cross- proj ect , 149 deploym ent , 188–189 developm ent environm ent , 167–169 docum ent at ion, 185–187 im plem ent at ion cycle, 179–181 I T environm ent , 152 m onit oring, 188–189 preparat ory, 149

-284-

Index

Convergent Architecture

proj ect m anagem ent , 159–163 refinem ent cont inuit y, 178–179 T- bar, 153–158 t est , 182, 184 XML ( eXt ensible Markup Language) , 39

-285-

Index

Convergent Architecture

List of Figures

List of Figu r e s Cha pt e r 2 : The Conve r ge nt Ar chit e ct ur e Roa dm a p— D e fin in g a n d m a n a gin g t h e big pict u r e Figure Figure Figure Figure

2.1: 2.2: 2.3: 2.4:

Roadm ap and anat om y of t he Convergent Archit ect ure. The developm ent m odel and t he layers below. The m odules of t he I T- archit ect ural I DE. The operat ional environm ent .

Cha pt e r 3 : The Conve r ge nt Ar chit e ct ur e M e t a m ode l— The vision a nd pr inciple s of t h e a r ch it e ct u r e Figure 3.1: The t hree pillars of a holist ic archit ect ure. I T- archit ect ure is only com plet e when it covers t hese t hree int im at ely relat ed t hem es. Figure 3.2: Converging business and I T m odels. Convergence = t wo perspect ives of one m odel. Figure 3.3: The convergent com ponent . Figure 3.4: I ndependent derivat ions of RASC ( sim ult aneously on different sides of t he world) . Figure 3.5: Com ponent m et am orphosis. Convergent com ponent s act ively support users during a given life- cycle st age and work cont ext .

Ch a pt e r 4 : Th e Conve r ge n t Com pon e n t M e t a m ode l— Com pon e n t s a s t he ve h icle of a r chit e ct u r e Figure 4.1: The foundat ion of convergent com ponent s. Figure 4.2: The archit ect ural layers. Convergent com ponent s form four layers t o best m anage a design. Figure 4.3: Convergent m odel- t o- com ponent relat ionships. Figure 4.4: Exam ple: Com ponent s in an e- paym ent port al. Figure 4.5: Exam ple: Model- t o- infrast ruct ure relat ionship. Figure 4.6: The t echnology proj ect ion com ponent . Figure 4.7: Convergent com ponent dim ensions and personalit ies. Figure 4.8: Enabling various dist ribut ion schem es. Figure 4.9: Proj ect ion of an ult ra- light weight client const ellat ion t o J2EE. Figure 4.10: Det ail: Ult ra- light weight client const ellat ion t o J2EE. Figure 4.11: Proj ect ion of a fat client schem e t o a CORBA I nfrast ruct ure ( Java/ C+ + ) . Figure 4.12: Assem blies as m acro unit s. Figure 4.13: The m odel- driven part s of t he accessor fram ework. Figure 4.14: Business engineering w it h obj ect t echnology. Figure 4.15: The basic OPR relat ionships and t he sem ant ics of OPRs. Figure 4.16: The convergent OPR com ponent s.

Ch a pt e r 5 : Th e I T- Or ga n iza t ion M ode l—Th e bu sin e ss of bu ildin g I T syst e m s Figure Figure Figure Figure Figure Figure Figure

-286-

5.1: 5.2: 5.3: 5.4: 5.5: 5.6: 5.7:

The The The The The The The

I T organizat ion in a business cont ext . t op- level I T organizat ion. archit ect ure organizat ion. I T support organizat ion. syst em developm ent organizat ion. canonical developm ent t eam . operat ional syst em s organizat ion.

Convergent Architecture

List of Figures

Ch a pt e r 6 : Th e D e ve lopm e n t Pr oce ss M ode l Figure 6.1: A specific inst ance of process archit ect ures. CA's relat ionship t o t hirdgenerat ion SW process fram eworks. Figure 6.2: The core analysis- by- design process. Sim ple and effect ive. Business com ponent s evolve increm ent ally. The first m odel is usually a real eye- opener. Figure 6.3: The effort split : Graduat ing t o convergence. Convergent Arciht ect ure deals wit h t he realit y of t he exist ng I T environm ent . Figure 6.4: The flow and scope of an it erat ion. Figure 6.5: Planning an it erat ion: The four- pass approach. Carry out t hese st eps wit h t he lead developers and prim ary cust om er. Figure 6.6: Work plan: The t ask ownership m at rix ( TOMA) is used t o com m unicat e work plans. Figure 6.7: Workflow, t ools, and core art ifact s. Figure 6.8: Recording and verifying business designs. Role playing verifies and debugs t he design and achieves consensus wit h dom ain expert s regarding requirem ent s and priorit ies. Figure 6.9: Model- driven t est infrast ruct ure. UML- driven ( OCL) t est generat ion, inst rum ent at ion, build, and runt im e.

Ch a pt e r 7 : Th e Ar ch it e ct u r a l I D E—Au t om a t ing t he a r ch it e ct u r e Figure 7.1: Archit ect ural I DE: Crit ical pat h coverage. Covering t he crit ical- pat h workflows. Figure 7.2: The m odules and environm ent of t he archit ect ural I DE. Figure 7.3: Orient at ion of t he C- BOM m odule. Figure 7.4: Business obj ect m odeling. Figure 7.5: Use- case scenario m odeling. Figure 7.6: Orient at ion of t he C- MOD m odule. Figure 7.7: Orient at ion of t he C- RAS m odule. Figure 7.8: Pat t ern- based refinem ent . Figure 7.9: C- RAS- OPEN pat t ern exam ple. Wit h perm ission ( Henderson- Sellers 1998, Fig. 2.3) Figure 7.10: Orient at ion of t he C- REF m odule. Figure 7.11: Convergent J2EE/ UML refinem ent . Figure 7.12: Det ails of t he default J2EE/ EJB m odeling st yle. Figure 7.13: The m ult ichannel assessor design. Figure 7.14: The process design. Figure 7.15: Orient at ion of t he C- GEN/ C- GEN- I DE m odule. Figure 7.16: Configuring cart ridges and proj ect s. Figure 7.17: Generat ing infrast ruct ure and environm ent . Figure 7.18: Using t he generat or I DE. The m et a- program m ing environm ent . Figure 7.19: Orient at ion of t he C- I X m odule. Figure 7.20: I m plem ent , deploy, and t est com ponent s. Figure 7.21: I m plem ent , deploy, and t est accessors. Figure 7.22: The operat ional deploym ent and assem bly t est .

Ch a pt e r 8 : Tu t or ia l Ex a m ple : Applyin g t he Con ve r ge n t Ar ch it e ct u r e Figure Figure Figure Figure Figure

-287-

8.1: 8.2: 8.3: 8.4: 8.5:

The ibank proj ect and reposit ory. CRC cards in t he ibank business m odel. Creat ing t he business use- case scenario. Recording a walk- t hrough. The init ially unrefined business m odel.

Convergent Architecture

Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

-288-

8.6: Refining t he Know account num ber responsibilit y. 8.7: Modeling t he balance at t ribut e. 8.8: Modeling t he m akeDeposit ( ) operat ion. 8.9: Modeling t he source at t ribut e. 8.10: Refined t o UML com ponent s. 8.11: The init ial C- REF/ Rose m odel. 8.12: EJB propert ies of t he account com ponent . 8.13: EJB propert ies of t he account Num ber at t ribut e. 8.14: EJB propert ies of t he Transfer com ponent . 8.15: The Generat e panel. 8.16: The Proj ect ions panel. 8.17: The Tools panel. 8.18: Rose log window. 8.19: Test client out put for t he iBank t ut orial. 8.20: The default accessor package. 8.21: St at e/ act ivit y diagram of t he Account _SEdit orDA accessor. 8.22: St at e specificat ion dialog. 8.23: Represent er specificat ion dialog. 8.24: Modified st at e/ act ivit y diagram 8.25: Assigning t he root accessor. 8.26: The Dependencies diagram . 8.27: The Generat e panel. 8.28: The Proj ect ions panel. 8.29: The cart ridge select or dialog. 8.30: Rose log window. 8.31: The running Web applicat ion.

List of Figures

Convergent Architecture

List of Tables

List of Ta ble s Cha pt e r 2 : The Conve r ge nt Ar chit e ct ur e Roa dm a p— D e fin in g a n d m a n a gin g t h e big pict u r e Table 2.1: Overview of Cum ulat ive I m provem ent s

Ch a pt e r 8 : Tu t or ia l Ex a m ple : Applyin g t he Con ve r ge n t Ar ch it e ct u r e Table 8.1: Not at ional Convent ions Table 8.2: Responsibilit ies of t he Account Business Obj ect Table 8.3: Responsibilit ies and Collaborat ors of t he Transfer Business Obj ect

-289-