TELKOM NIKA , Vol. 13, No. 4, Dece mb er 201 5, pp. 1466 ~1 477   ISSN: 1693-6 930,  accredited  A  by DIKTI, De cree No: 58/DIK T I/Kep/2013   DOI :  10.12928/TELKOMNIKA.v13i4.2388    1466      Re cei v ed Au gust 3, 201 5; Re vised Sept em ber  8, 201 5; Acce pted  Octob e r 2, 20 15   Service Engineering Based on  Service Oriented  Architecture Methodology      Suhardi 1 , Ro bin Doss 2 , Purnomo Yus t ianto 3   1 School of Elec trical Eng i ne eri ng an d Informa tics,  Institute of  T e chnol og y B and un g, Indon esia, 40 13 2   2 School Inform ation T e chno lo g y , D eaki n  Uni v ersit y , Mel b o u r ne, Australi a, 312 5   *Corres p o ndi n g  author, e-ma i l : suhard i @stei . itb.ac.id 1 , p y us tian@ deak in.e du.au 3       A b st r a ct   Service E ngi n eeri ng (SE) a n d  Servic e Orie nted Ar ch itectu re (SOA) origi nally r e si de o n  different   plate aus  of d i s c ipli ne. SE  is  d e fine d as  a  set  of acti v i ty intro duci ng  a  new  b u sin e ss serv ic e, w h ile  SOA i s  a   technic a l a ppr oach to re defi ne an  enter pri s e busi ness  pr ocesses as  a  set of IT  enabl ed servic es. T h is   pap er pro pos e s  a SOA emb edd ed SE fra m ew ork as  a  c o mpre hens ive appr oach in  re -defin ing busi n ess  service a nd its  IT  imple m e n tation. After an  intr oducti on, a review  of existing SE fra m ew orks and S O A  meth od olo g i e s  is pr esente d  i n  the  pa per. A fterw ard,  a co mp lete S E  fra m ew ork  is pr o pose d  w i th se veral   results on  earl y  case studi es. A survey resul t s are t hen pr e s ented to pr ov e the usa b il ity and b e n e fit of th e   prop osed fra m ew ork. T he framew ork is  des ign ed a nd  pr o pose d  to he lp  practitio ners a nd res earch ers  to   cond uct servic e eng in eeri ng  by empl oyin g p r incip l es a nd  method ol ogy offered by SOA a ppro a ch.      Ke y w ords : Se rvice Eng i ne eri ng, F r amew ork, SOA,  Busines s Model C anva s , Service Blue printi ng      Copy right  ©  2015 Un ive r sita s Ah mad  Dah l an . All rig h t s r ese rved .       1. Introduc tion  The glo bal  shift toward s  a se rvice - b a s ed  econom y has b r ou g h t importa nce to the  con c e p t of S e rvice  Engi ne ering  (SE). E norm o u s   cha nge s in  glob a lized  bu sine ss e n viron m en t in  recent yea r s  have ma de  service  inn o va tion a  critic al prio rity  for all busi n e s s  ma nage rs.  B u si n e ss  entities comp ete to provide  the best valu e for cu stom e r s by taki ng a d vant age of t he co mpetitive  busi n e ss  envi r onm ent. SE method s hav e the pote n tia l  to help the  pro c e ss  of se rvice in novati on  to deliver inte nded a nd de signed value  o f  a service to the cu stome r .  Information  T e ch nolo g y (I T) h a s be en  an imp o rta n t  comp one nt in  the recent g r owth  of  the se rvice i ndu stry. It also takes  a central role  in  innovating n e w servi c e s . Therefore, a s  a  pra c tical a nd  an academi c   field, SE requires  com p lem entary analy s is from IT poi nt-of-vie w . As a   result of thi s  tren d, it is  imperative th at   the  field  sho u ld be a d vanced and   enla r ge d wi th   partici pant s, not only from busi n e ss an d  managem ent   field, but should also invol v e practition e r s  and re se arch ers  with IT expertise.   The te rm ‘ se rvi c e  en ginee ring ’  (SE) wa s first m entio ned  du ring  th e mid - nin e tie s  a s  a  techni cal di scipline in syst e m atic develo p ment  and d e s ign of services u s ing a ppropriate m odel s,  method s, a n d  tool s [1]  SE encomp a s ses b r oad  range  of a c ti vities sta r tin g  from  bu sin e ss  strategi c l a yer to  pro c e s s d e si gn a n d  its d e taile d implem ent ation in te ch nical l a yer.  The   introdu ction  Service S c ie nce, Ma nag e m ent and En ginee ring (S SME)  as  a di sci pline reiterates  the emph asi z e on  an in terdiscipli nary  approa ch, combi n ing m anag ement  and en gine e r ing   theorie s, in cl uding from IT disciplin e, in the obj e c ti ve of improvi ng the comp etitiveness in  the   orga nization  based on g r o w ing  servi c e s  need s in the  busin ess en vironme n t [2]. To handl e such   compl e x und ertaki ng, a fra m ewo r ks a n d  method s to  guide the p r o c ess is requi re d [3], which  can  c o ver through the tec hnic a l as pec t  in the IT layer.    An emergi ng  appro a ch from IT discipl ine,  Service  Oriente d  Architecture (SO A ), wa s  introdu ce d wi th the capabi lity of bridging the bus in e ss p r o c e ss (BP) requi rem ents with the  IT  developm ent  pro c e s ses im plemente d  a s  servi c e s  co mpone nt [4]. Compl e me nting SE with SOA  approa ch, th erefo r e,  sho u l d be  an i dea l app roa c h   fo r bu sin e ss  se rvice  develo p m ent to a n swer  the comp etitiveness ch all enge an d the deman d fo r agility in the se rvice i ndu stry. Whil e a   methodi cal f r amework to   guide  a  se rvice  engi nee ri ng p r o c e s s i s   req u ire d , a  formali z e d  a nd  pra c tical  fram ewo r k which  can  gui de  an  appli c atio n o f  the SE  with  SOA app ro ach is still l a rge l y  untou che d . Some ea rly propo sition s ha ve already  b een mad e  [5] [6], but  these works did  no t  Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 16 93-6 930   TELKOM NIKA  Vol. 13, No . 4, Decem b e r  2015 :  146 6 – 1477   1467 delved into t he detail s  of  SOA method ology, and  di d not p r ovide d  ca se  studi es a s  a  proo f of  c o nc ep t.  This pa per p r opo se s a fo rmali z ed SE fram ework, spe c ifically embedd ed wit h  SOA  approa ch. T h ree  charact e risti c s are  con s id ere d  i n  formul atin g the p r op o s ed f r ame w ork:  simpli city, co nformity and   uniformity. Th e frame w o r k i s  de sig ned  to  simplify the  pro c e s s in te rms   of easine s s of adoption  and implem e n tation, and   at the same time it also ensu r e s  the  compl e tene ss and  app ropriate ne ss  of the solu t i on provided  for given  situation in  an  orga nization.  The exi s ten c e of the fra m ewo r k is  also  desi gne d to create th e unif o rmity of se rv ice   engin eeri ng pro c e ss acro ss multiple  i m pleme n tati o n s. Th e pro positio n  of the fram ework is  pre s ente d  in this pa per  with ca se stu d ie s and  survey  results on its i m pleme n tatio n .      2. Ser v ice Engineering F r ame w o r ks   The d e finition  of se rvice  e ngine erin g wi th re g a rd  to  e-servi c e  sco pe is sp ecifie d as “ an   approa ch that  pro v ide s  a di sci pline for  using  m odels a nd tech niqu e s  to guide th e  unde rsta ndin g ,  stru cture, de sign, im plementat ion, dep loym ent, docum entation,  operation, maintena nce and   m odification of  e-servi c e s ” [7]. Within this  sc ope, the  objec tive  of SE framework  is to provide t h e   servi c es in IT layer,  specifi c ally in the f o rm  of  web services whi c h  w ill all o w a  high degree  of  automated i n tera ction a m ong  se rvices. The r efo r e,  it is high ly desirable  to redefin e  the  architectu re o f  the enterpri s e usin g app ro ach e s fro m  Service  Orie nted Architectu re (SOA ).  From SE poi nt of view, two frame w o r ks for desi gnin g  (ne w )  se rvice s  we re  sel e cted to   be a com parative base to  propo se the  new fram e w ork. Th e first  framework wa s take n from   cla ssi c  NS D  con c e p t, prop ose d  by  Lin  a nd  Hsi e h  [8], and  app rop r i a tely nam ed  as  Ne w Servi c e   Develo pment  (NS D ) f r am ewo r k. Ba se d on ITIL , t he second f r amework  wa s introdu ce d  as  Servic e Sys t em Developm ent Process (SSDP) [9].  Both frame w orks p r op ose  the combi n a t ion use of v a riou s ma na gement a nalysis tool s  su ch a s : Fea s ibility Study, Socio T e chn o -Economi c al  Analysis, En vironme n tal  Scanni ng, Trend   Analys is , B C G matrix, and Quality Func tion  Deplo y ment (Q FD). A com pari s on  can  be  m ade   betwe en the  two focusi ng  on the ap pro a ch i n  de sign ing a servi c e,  spe c ifically in modeli ng t h e   serv i c e.    The first fra m ewo r k, the NSD fram ework, def in es t he Service  Desig n  as two  distinct  stage s: (1) service  mod e li ng a nd  (2) service  im ple m entation. T he  servi c e m odelin g itself  i s   comp osed f r om fou r   com pone nts:  (1)  prod uct  mod e l, (2 ) p r o c e s s m odel,  (3 )  resou r ce mo del,  and (4) ma rketing co ncept . Among othe rs, the  UML  notation is  e m ployed a s  a  tool for prod uct  model. Se rvice  blue printi ng te chni que  is  su gge ste d  a s  a  p r o c ess m odel  tool. Th e ma in   prop osed to o l s of  servi c e  desi gn in  NS D fra m ewor k is  the QF D matrix.QFD  i s  sugg este d as  a   tool to visuali z e th e  cu sto m er  nee ds du ring  the  se rvice  develo p m ent p r o c e ss.  A modified  Q F D i s   also  su gge st ed a s  a  service-pl anni ng  matrix to  d i splay  cu sto m er requi re ments, te chn i cal  measures, target values, a nd com petitive analyse s in  the form of House of Quali t y (HOQ).   The se con d   frame w o r k (SSDP) defi nes  the se rvice  d e si gn and develop ment  a s   analyzi ng service req u irem ents into the i dentificatio n of (1) servi c e  entities funct i ons, (2 ) servi c e  interfaces,  (3 ) se rvice inte rope ra bility,  and (4)  se rvice level a g re ements.  Whil e not explicit ly  mentionin g  SOA approa ch , this definition ba sically embodi es th e SOA desig n approa ch. In  modelin g the servi c e, SSDP utilize s  a se rvic e  meta-mod el  [10] to he lp stakehold e rs  con c e p tuali z e  the servi c e value chain.   The two fram ewo r ks  are in here n tly an it erat ing  p r o c e s s of  contin u ous imp r ove m ent, and  thus the  re sul t  of each  stag e is a fe edb a ck fo r  the  nex t iteration. Also, tests  coul d  be cond ucte d  in the end of  each  step, ensurin g co n f ormity of  the step re sults with the inp u t spe c ificati ons  stated in the  begin n ing of the step, befo r e deci d ing to  contin ue to the next step.  A combin atio n and ge neralizatio n bet wee n  t he two has al so b een propo se d, defining  the Gen e ral  Service E ngi neeri ng F r am ewo r k [11]. It  is  comp osed  from fou r  g r oup s of a c tivities:  (1) Id entificati on, (2 )  De sig n , (3) Develo pment, an d (4) O peration.  This  pap er i s  a foll ow-up   on  this  con c e p t, by providi ng  elabo ration  d e tails i n to the  pro p o s ed  fra m ewo r k a nd  by focu sin g  t h e   highlight on t he role of SO A methodolo g y in SE Framewo r k.          Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM NIKA   ISSN:  1693-6 930     Servi c e Engi neeri ng Ba se d on Service Oriente d  Architecture Met hodol og y   (Su hardi )  1468 3. SOA Meth odologies   SOA is d e fin ed a s   softwa r e a r chitectu re ba sed  on l oosely co upl ed softwa r e  servi c e s   whi c h inte grated into a  distri buted  com putin g  system, b y  mean s of  se rvice - o r ie nted   prog ram m ing  [12]. In SOA perspe c tive, se rvice s  a r e the  buildin g blo c ks of a n  enterpri s e.  An   enterp r i s e i s  defined  by its pool  of se rvice s , bot h  available i n te rnally an d p ublicly, an d the   intera ction p a ttern betwe en the se rvices. The serv i c e interactio n  is not boun d internally i n  an   enterp r i s e, but the busin ess land scap e or the bu sine ss enviro n ment is also comp rised  of  intera cting se rvice s  amo n g  various o r g a n izatio ns . Th us, the well -b eing of an en terpri se a nd the  busi n e ss e n vironm ent is de termine d  by t he implem ent ation quality of these servi c e s .  Since its in ception in th e  mid 20 00’s,  the SOA ap proa ch  ha s e x perien c e d  g r owth  in  maturity an d  rate  of a d o p tion. While  several m a in  co ncepts were  inde ed  converg ed, S O A  contri butors  are  still unable to provide on a si ngular  cohesiv e  view on the SOA adoption.  Variou s met hodol ogie s  a r e offere d in  the form  of step-by-ste p  guidan ce in  desig ning t h e   impleme n tation of SOA. F r om compilin g works on  SOA methodol ogie s  [13] [ 14] [15] [16]  [17],   we  can  coll e c t at lea s t 15  different met hodol ogie s . T w o mo st po p u lar SOA m e thodolo g ies a r e   (1) IBM' s SOMA [18] and (2 ) Thom as Erl' s SO A [19], often  labeled a s  Mainst ream  SOA  methodol ogy (MSOAM) [15 ] .  IBM’s SOMA is a highly re comm end ed SOA method due to its co mpre hen sive ness and   its vast indu st rial ad option [ 20] [14] [17]. It cove rs  a co mplete cy cle  of servi c e en ginee ring, fro m   busi n e ss  sid e  to the technical impl em entation.  The  method co n s ist s  of six main stag es:  (1)  busi n e ss tra n sformation  analysi s , (2 ) identificatio n, (3)  spe c i f ication, (4 ) reali z ation,  (5)  impleme n tation, and (6) d eployment -m onitorin g . Each  sta ge in -tu r n con s ist s  of three to four  sub   st age s.        Table 1. Stag es of SOMA Methodol ogy [1]        A variation of SOMA prop ose s  the u s e  of Compon e n t Busine ss  Model (CBM), as an   analytical too l  in the early stage of the  methodol o g y, during sta g e  1 to 3. CBM is basi c all y  a  matrix of enterprise’s  busine ss  com petencies against account ability level, i.e. directing ,   controlling  an d executing [21]. The resulting elem en ts of the mat r ix are d e fine d as b u si ne ss  comp one nts.  Each b u si ne ss compo nent  is defin ed to   have attribute s  of: (1 ) pu rp ose, (2)  activi ty,  (3)   re so ur ce, (4)   gov e r na n c e,  a nd (5 ) s e rv ice s  offe re d. The  matrix  ca n b e  u s e d   to determine   the   importa nce of each b u si ne ss  com pone n t, and ulti mately to define new  servi c e o ffering.  A compl e te  SOMA meth odolo g y, therefore,  can  b e  co nsi dered  as SE fra m ewo r k in   itself. Yet, ad opting SO MA inde pend entl y  has be en  made  difficult  due  to the  li mited availa b ility  of detailed  SOMA reference ma terial.  Combining  SOMA with   SE framework therefore  will  necessitate t he  removal  of  seve ral  pa rt  of the  m e thod ology d ue to  t he p r o c e s s re dund an cy. Wi th   the help f r o m  a detail e d  referen c e,  SOMA meth odolo g y ca n  still be  useful in buil d ing  SE  frame w ork, e s pe cially in th e spe c ificatio n stage a nd o n wa rd.   Another well -kno wn  S O A methodol ogy is  the  one  de vised by T h o m as E r l. In h i s bo ok  [19-6] he el a borate d  a def initive refere n c e fo r SOA i m pleme n tatio n , MSOAM. The metho d o l og y  con s i s ts of se ven stage s of  activities: (1 ) Ontol ogy De finition, (2) B u sin e ss Mo d e l Alignment, (3)  Service O r ie nted Analysi s , (4) Service Oriente d  De s i gn, (5) Se rv ice D e v e lopm ent, (6) Serv i c e   Testing, a nd  (7) Se rvice  Deployment. T he emp h a s is  of MSOAM elaboration i s  durin g an alysis  and de sig n  a c tivities. This  is evident by the num b e r of  sub-stag es d e fined for the  two stag es.    Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 16 93-6 930   TELKOM NIKA  Vol. 13, No . 4, Decem b e r  2015 :  146 6 – 1477   1469 While  providi ng detail ed p r escription  o n  analy s is  a nd de sig n  a c tivities, MSOAM doe s  not provide  el aborate g u ida n ce  for  activities  dur i ng bot h  prelimina r y busi n e s s  anal ysis and   po st - desi gn. The s e lacks m a ke it some wh at appr opri a te to be co mbined  with  SE framework.   MSOAM met hodol ogy st re ngth in  analy s is and  de sig n  sta ges is q u ite usef ul to  be ad opted,  but  care  sho u ld  be ta ken  to  ensure  that n o  a c tivity red unda ncy i s   p e rform ed. Ad ditional  activities  sho u ld al so  be define d  in  the SE framewo r k to fill the gaps fo r pre - de sig n   and po st-d esign   activities in original MSOA M.       Table 2. Stag es of MSOA M Methodol o g y [6]  1.  Define Re lev a nt Ontology 2.  Align Rele va nt   B u s i nes s  Models 3.  Per f orm  Ser v ic e Ori e nt ed A n al ysi s 4.  Per f orm  Ser v ic e Ori e nt ed D e s i gn 5. D e ve lop Se rvic es 6. D e ve lop Tes t  S e rv ice  Oper at ions 7. De ploy S e rv ice s 3. 1 .  De f i ne  B u s i n e s s   Re q u ir em en t 3 . 2.  Id ent if y Aut o m a ti o n  S ystem 3 . 3. Mo de l Ca nd id ate   Se r v ice s 3 . 3 . 1.  De c o m p o s e B u s i ne s s  Pr oc e s s 3 . 3 . 2.  I d e n t i f y  O p era t io n Ca nd id at e 3. 3.3 . Ab stra ct Or ch estr at io n L o g i c 3. 3.4 .  C r eat e S e r v ice  C a n d i d a t es 3. 3.5 .  R e fi n e  &  Ap pl y Se rvi c e  Or ie nt ati o n 3. 3.6 .Ide n ti fy Ser v i c e  C o mp osi t i o n s 3. 3.7 . R e vi se O per a t i on  Gr oup i n g 3. 3.8 .  An al yze  Pr ocessi n g  R e q u i r em en ts 3 . 3 . 9. I d en t i f y  A p pli c at io n  S e r v ic e  O p er at io ns 4. 1 .  Co mp os e  SO A 4 . 2. D e sign Ent i t y - C e n tric  Bu si n e ss  S e rv. 4. 3  Des i gn  Ap pl ic at io n   S e rv ic e s 4. 1.1 .  C h o s e S e r v i c e L a yer 4. 1.2 .  Po si ti on  Co r e  St and ar ds 4. 1.3 .  C h o o se  SOA  Exte nsi o n s 4 . 4. D e sign Task-Cent r i c  B u sine ss  Se r v . 4 . 5 D e sig n  S e r v . O r i e n t ed  Bu si ness  Pr ocess 3. 3.1 0 . C r ea te  App l . Se rvi c e  C and i dat es 3. 3.1 1 .R evi s e  Se rvi c e  C o m posi t i o ns 3. 3.1 2 . R e vise  Op er ati o n Gr o upi n g 4.4 . 1.  D e fi ne  w o r k fl ow  l o gi c. 4 . 4.2 .  De rive  in itial   i n te rface . 4.4 . 3.  Ap pl y Se rvi c e  Or ie nta t i o n . 4.4 . 4.  Sta n d a r d i z e S e r v i c e In te rfa c e. 4.4 . 5.  Ide n ti fy  Re qu ir e d  P r o c essi ng . 4.5  D e si gn  Se rv.  Or i ent ed  Busi n e ss Pr o c ess 4.3 . 1.  R e vi ew  E x ist i n g  S e r v i c es. 4.3 . 2.  C onf ir m  C o n t ext 4.3 . 3.  Derive In itial In terface 4.3 . 4.  Ap pl y Se rvi c e - Or i e n t at io n. 4.3 . 5.  Sta n d a r d i z e S e r v i c e In te rfa c e 4.3 . 6.  Ad d Sp ecu l a t i v e Fe atu r es 4.5 . 1.   Ma p Out Inte ra cti o n   Sce nar i o s 4.5 . 2.  D e si gn  Pr oce ss Se rvi c e  Int e r f ace 4.5 . 3.  For m al i z e Pa r t ne r S e r v . C o nver sa tio n 4.5 . 4. De fi ne  Pr oce ss Lo gi c. 4 . 4. 5 .  A lig n I n te ra c t io n S c en ar io s   & R e f ine       The hea rt of SOA desig n activity is  the  spe c ifica t ion activity,  employing m odelin g  notation. A review arti cle  [22] reveals  six av ailable  notation s  for SOA modelin g: (1) SOA-RM,  Referen c e M odel for SOA ,  (2) SOA-RFA SOA Referen c e Archit ecture Fou n d a tion, (3) SO A  Ontology,  (4 ) SOM F , S e rvice - O r ient ed M odelin g  Fra m e w ork, (5) PIM4 SOA, Platform- Indepe nde nt Model fo r S O A, and (6)  SOAML, SOA Modelin g  Lang uage. F o r a  simpl e   SOA  impleme n tation, a ba si c  UML o r  a  Th omas E r l’s  n o tation is  suff icient, but fo r a co mplex  SO A  impleme n tation, SOAML,  as a n  exten s i on of UM L,  is sug g e s ted d ue to its referential availabi lity  and vast ad o p tion in seve ral SOA methodolo g ies.       4. The Propo sed Frame w ork   The propo se d frame w ork i s  drawn from   generalized  SE approa ch,  describ ed in  se con d   part of this  article,  with spe c ific u s e  of  busin ess  analysi s  tool s, and  comb ined with S O A  methodol ogy, in o r de r to  achieve  a  more  prac ti cal  ap pro a ch   in servi c e engin eeri ng. The   prop osed fra m ewo r k con s ist s  of fou r  stage s: (1 ) identificatio n stage, (2) d e sig n   sta ge,   (3)   developm ent stage a nd (4 ) deployment  stage.   The first sta ge, the id ent ification  stag e, is  the  bu siness  side  a nalysi s  in  wh ich n e w  (ele ctro nic) service s  pote n t ial are identif ied and p r op ose d  with an alysis of exist i ng co ndition  of  the whol e org anization enti t y. The desig n stage, a s   th e se con d  sta ge, con s i s ts  of both bu sin e ss  desi gn an d techni cal d e si g n  pro c e s s. Th e se rvice s  are desi gne d or rede sign ed i n  this sta ge with  rega rd to the  existing condi tion of the org anizati on. Implementin g the frame w o r k f o r the first tim e   in an  org ani zation i s   also an  opp ortu nity to adopt  SOA app ro ach i n  the  o r gani zatio n  o f  IT  system. The  deci s io n of employing SO A in top-do wn or bottom - u p  mann ers is  made d u rin g  this  stage. The   thi r d stag e,  the devel opm ent  stage, i s  a  so ftware  en gine ering  p r o c e s s co nformi ng t o   SOA approa ch. The la st  stage, the  deployme nt st age,  con s ists of migrati ng to pro d u c tion  environ ment,  along with  applying mo nitoring m e a s ures a nd setting up SOA Governa n ce to  ensure the  co nformity of syst ems  for future improvements .  Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM NIKA   ISSN:  1693-6 930     Servi c e Engi neeri ng Ba se d on Service Oriente d  Architecture Met hodol og y   (Su hardi )  1470     Figure 1. Pro posed Servi c e Enginee rin g  Fram ewo r k      4.1. Identific a tion Stag e   In the identif ication  stag e, new  se rvice ( s)  pote n tial  for a  cu stom er i s  identifie d and   defined. The  unde rlying m o tive  for  i nno vating  ne w serv ice  i s  to  improve  custo m er val ue. In  that   sen s e, the  service i dentificati on  stage  must co nsi s t of steps to  identify services  with hi gh  cu stome r  val ue. Busi ne ss Model   Canv as  (BMC) [2 3 ]  is u s e d  in t h is  stag e a s   an a nalysi s  a nd  modelin g too l  of the fi rm  to identify co mpone nts  wit h  st rong  pot ential to im p r ove the  val ue  prop ositio n to the custom ers. Nine blo cks of BM C are  the analytical  base s  for im proving the firm  value. The potential of improvem ent might aris e fro m  custo m er  segment, reve nue stream, co st  stru cture, value pro p o s itio n, or in key a c tivities.          Figure 2. Business Mod e l Canva s  Tem p late       The ide n tifica tion stag e sh ould  start wit h  "as-is BM C", but the rea l  result of the BMC  analysi s  i s  the ne wly propo sed BM C: the "to-b e  BMC". Thi s  ne w BM C rep r e s ent s  the   prop ositio n o f  se rvice  inn o vation. As  an exa m ple,   the de ci sion   to improve t he Key A c tivities  block might require a crea tion of  service innovation  in supp orti n g  activities. Therefo r e, a ne w  sup port  se rvice  sho u ld b e  desi gne d an d implem ente d  to incre a se  the effective ness of the  key  activity pro c e ss. T h is type  of se rvice  can be  cate g o rized a s  " s e r vice -a s-sup p o rt". In anoth e r  ca se, the  de cisi on  of improvement mi g h t re side  in  t he Valu e Pro positio n blo c k. In thi s   ca se a  new  se rvice  sho u ld b e  propo sed fo r the custom er s,  in t he f o r m  of  dire ct   cu st ome r s f a cin g   servi c e s . This type of service can be  ca t egori z e d  as  “servi ce -a s-p r odu ct”.   Another com m on to ol to i d entify the  service  in novatio n is the  qu est i onnai re  meth od. Th e  method i s  re gularly u s ed  durin g a ma rket re se arch  activity. The use of q u e s tionnai re i s  pa rt of  true requi rem ent investig ation, as th e requireme nt  is  defined ba sed  on actu al intera ction wi th   pro s pe ctive  cu stome r s [5 ]. An analysi s  from  th e q uestio nnai re  data might i n stigate  a n e w  servi c e inn o vation. For example, the q uestio nnai re result might sugge st an im provem ent in the  firm key activ i ties. Therefo r e a service innovat ion  ca n be intro d u c ed from “se r vice-as-sup port”  categ o ry to enhan ce the a c tual key acti vities.     Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 16 93-6 930   TELKOM NIKA  Vol. 13, No . 4, Decem b e r  2015 :  146 6 – 1477   1471     Figure 3. Stages of Identifi c ation Stage       Another  com m on form of true requi rem ent invest igati on is ob se rva t ion. Obse rva t ion is a   method  to  ca pture  the i n fo rmation  ba se d on  the   re al -wo r ld  situ ation. Ob se rvati on p r o c e s s  can   also  in clude   que stionn aire , or inte rview activiti es.  During  the  ob servation th e rese arche r  m u st   dire ctly visits or expe rien ce s  the   site  of actu al b u s ine s s p r o c e s s an d  cu sto m er t r an sa cti on  perfo rmed.   A servi c e i n novation in t hese day s freque nt ly lea d s to th e im plementatio n  of ne w   Information T e ch nolo g y (IT) compo nen t [24]. An  input from IT asse ssm ent is t herefo r e  will be   valuable i n  th e ide n tificatio n  sta ge. Th e  latest  tre nd i n  IT, su ch  as cloud  com puti ng, could  se rve   as an imp o rta n t element in the servi c e in novation.   The fin a l result of a n  id e n tification  sta ge i s  p r e s e n t ed in  the fo rm of  "to-b e  BMC"  compl e me nte d  with sum m ary of the  servi c e inn o vation idea.  Both comp onent s sh oul d be  formali z ed a s  a servi c e ide n tification do cument.    4.2. Design  Stage   The de sig n  st age of the p r opo sed fram ewo r k i s  divid ed into two  sub-stage s: (1 ) se rvice  pro c e s s de si gn a nd  (2 ) S O A de sign.  T he g oal  of th e  first  su b-stag e, the  s e r v ic e p r oc ess  de s i g n ,   is to cre a te the de sign of  the service defined  fro m  analysi s  in the identificat ion stag e. The  se con d   sub - stage, SOA  d e sig n , is the   sub - sta g e  to  elabo rate  the  de sign  u s ing  SOA a pproa ch  and metho dol ogy.  Duri ng service pro c e ss d e s ign, the se rvice bl uep rint ing techni que  [25] is prop ose d  to  rep r e s ent ho w  the   servi c e sho u ld be del ivered   to  the   cu stome r . Se rvice  blue pri n ting techniq u e  is  norm a lly u s e d  to d e scribe   existing  se rvice  or to  rep r e s ent th e  se rvice i nnovatio n .  The te ch niq ue  define s  five layers fo r se rvice intera cti on: (1 ) phy si cal eviden ce,  (2) cu stom e r  action, (3 ) on- stage  co ntact  employee,  (3) ba ck-stag e  conta c t em pl oyee an d (5 )  sup port p r o c ess. In additi on   to se rvice  blu eprintin g  te ch nique, Bu sin e ss p r o c e s s diagram (BPD), with  its  B u sin e ss  P r o c ess  Modelin g No tation (BPMN) a s  the to ol, can b e  u s ed to el abo rate the p r o c e ss of  serv ice   innovation.           Figure 3. Service Bluep rint  Template   Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM NIKA   ISSN:  1693-6 930     Servi c e Engi neeri ng Ba se d on Service Oriente d  Architecture Met hodol og y   (Su hardi )  1472   The intention  of the service   design  sub - stage is to have an ov ervie w  of the servi c e. The  result from th is process wi ll be use d  as a refe re nce  to determin e  the se rvice o peratio n in th e  SOA implem entation sub-stage.   The se co nd sub - sta g e   in desi gn stag e   is  t he SOA   impleme n tation  sub - stage . In this  sub - sta ge, a n  SOA meth odolo g y will guide the  cre a ti on of se rvice de sig n  in  IT terms. An  SOA  methodol ogy  commo nly involves an i dentificatio n  activity followed by de si gn activity. The  purp o se of i d entification  is to ide n tify the candi d a te  servi c e s , whil e the  purpo se of the  de si gn   stage i s  to d e fine the serv ice s  sp ecifi c a t ion,  such a s  servi c e  contract and  ch oreography. In the   prop osed f r a m ewo r k, so me pa rt of  SOA se rv ice  identification  ha s al rea d y bee n p e rfo r med  durin g the previous  step, in the  form of to-be BMC,  service bl uep ri nt and BPMN. These a r tifacts  are th e sta r ti ng poi nt for  Service i denti f ication  in  the  SOA metho d ology. For ex ample, the  case  of adopting T homa s  Erl’s  MSOAM methodol ogy, the fi rst two step s of it, Ontology Definition  an d   Busine ss Mo del Alignm en t, can b e  si m p lified by  em ploying the  result s of BM C an alysi s . T he  same id ea is also a ppli c abl e to steps 3.1  (Bu s i ness Re qui rement Defini tion) and 3. 3.1  (De c o m po se  Busine ss Pro c e s s) in  whi c h the p r eviou s  result from  Busin e ss P r oce s s Di ag ra m  and Servi c e  Bluepri n ting can be u s ed.           Figure 4. SOA Methodolo g ies in  De sig n  Stage       4.3. Dev e lop m ent Stag e   For a full-fle d ged SOA im plementatio n, several co m m ercial platfo rms a r e avail able to  sup port serv ice-ori ented  comp uting a ppro a ch  of SOA, such  as IBM We bSphe re, SAP  NetWeaver,  BEA Weblogi c, and Oracl e  SOA Suite.  An open  source alternati v e also exi s ts as  J B oss  Enterpris e  SOA Plat form.  For ou r goal  with the pro p o se d frame w ork in a  simpl e  deployme nt, Micro s oft's  Wind ows  Comm uni cati on Fo und atio n (WCF) te ch nology i s   re commen ded  d ue to it s  simp le develo p me nt  requi rem ent  comp ared to  other platform. Selecti n g  WCF  will h e lp defini ng  activities in  stage   4.1.2 (Positio n Core Stand ard s ) an d 4.1 . 3 (C ho ose SOA Extensio ns) of MSOA M. Using  WCF   as th e  co re  stan da rd  a nd SOA  technolo g y al so  sim p lify sta ge 4.2  (De s i gn e n tity-ce n t ric  busi n e ss  services) and 4. 3 (De s ig n ap plicatio n se rvice) d ue to th e automation  of WDSL (Web   Service  Defin i tion Lang uag e) gen eration  in WCF.   Duri ng  and i n  the e nd  of develop men t  stage,   seve ral te sts fo r t he  system m u st b e   con d u c ted. Due to the nature of SOA implem e n tation as d i stribute d -m e s sagin g  syst em,  p e r for m in g un it te s t  an d sys te m  te st fo r la rge  scal e  or  enterpri s e - wide  SOA  system  ca n b e   a  chall engin g   unde rtake. Propo sition fo r testing  SOA  (we b )  servi c e s  involves gene rating t e st  requi rem ents by using Se rvice Me ssag e Flow  Di ag ram (SMF D)  cal c ulatin g e v ery con n e c tions  variation, and  the use of test  tools for  web se rvice, such a s  SoapUI to WebInjec t [26].    Before movin g  to deployment stage, a User  Accepta n ce Te st (UA T ) must be p e rform e d   to ensu r e  con f ormity betwe en the re sult  of devel opme n t and the re sult from a nal ysis an d de si gn   stage, al so to  verify that th e servi c e sy st em meet the use r  re quire ment.    4.4. Deplo y ment Stag e   A  su ccessful testing re sult can be deplo y ed  and  furth e r mo nitored  and e nha nce d  for the   system. Oth e r wi se, the  proce s s  mu st  be re peate d   by analyzi n g  and d e termi n ing  step s to  be   reiterated, in  analysi s , de si gn o r  p r ototyping  stage,   a nd repe ating  the sta ge to f i x the deviati on.  Entering the  deployme nt stage, any measu r e s   for m anag ement chang e of the organi zatio n  is   plann ed and  executed to  ensu r e a smooth tran sit i on from the  existing system. Monitori ng  activities sho u ld  also  be condu cted  to observe  t he  real-wo r ld be h a vior an d pe rforman c e of t h e   Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 16 93-6 930   TELKOM NIKA  Vol. 13, No . 4, Decem b e r  2015 :  146 6 – 1477   1473 newly i n stall e d service  system and  its in frastruc tu re  a s  a  me an s fo r  continu o u s l y  improvin g t h e   servi c e. Fo r  enlarging th e  impl ementati on of SOA a ppro a ch, SO A governa nce sho u ld al so  be   desi gne d and  put into place.  The followi ng  table summ arizes the  co nce p t and to ols empl oyed  along with  artifact s  prod uced du ri ng ea ch sta g e  of the framewo r k.       Table 3. Prop ose d  SE Fra m ewo r ks To o l s and Artifa cts  Stage  Tool s   A r t i fac t   1. Identif y  True  requireme nt     BMC      Questionnaire re sult   Observation ana y s is   As-Is BMC   Service Innovation  To-be BM C   Business Ser v i c e Catalog  2. Design  Service Blueprinting  BPMN  SO A Method   (e.q.  MSOAM/SOMA )  Service Blueprint  BPD  UML / SO AML   IT Service Catalo g  3. Develop  SO A Platform   (e.q. WCF )   IT Service  Implementation   Unit and s y stem  test  r e sults  UAT result   4. Deplo y   SOA Gove rnanc e  SOA Policy  &Sta ndards   Monitoring meas ures      5. Case Stud ies  As an  atte mpt to form alize  the  propo sed  Serv ice En gine ering F r ame w ork,  the  frame w ork  was in cre m ent ally built by usi ng  com p onent s of the prop osed  frame w ork a n d   unde rtaki ng the followi ng case  studie s . The detail s  are pre s ente d  b e low.     5.1. First Ca se Stud y   The first case study wa s  perfo rmed b e f ore a  definiti v e formal fra m ewo r k wa s  devise d .  The locus of the study was a State Palm Plantat ion Firm. The goal  wa s to provid e an integrate d   Enterpri se  Reso urce Plan ning (E RP) b a se d on  SOA  approa ch. As a service e ngine erin g work,   the study em ployed SOM A  as its SOA  methodol ogy.  From the th ree ide n tificati on techniq u e s  in   SOMA: doma i n decompo si tion, goal se rvice modeli n g and existin g  system a n a l yst, only the  first  two are pe rforme d, due t o  the minim a l IT resou r ces availa ble  in the firm. In modeli ng the   servi c e s  the   work enh an ces th e u s e  of  UML  with  SO AML in th e di agra mmatical  form s of  Service  Specification,  Service Inte rface  an d S e rvice  R eali z ation. Finally , a prototype  of the  se rvice   desi gn wa s p r odu ce d by using  WCF te chn o logy. Thi s  ca se  study serve d  as a  basi s  to asse ss  the context of a SOA Methodolo g y with in a Service E ngine erin g proce s s.    5.2. Second Cas e  Stud y   The se con d  ca se study was a se rvice  engin eeri ng  study on th e p r ocess of la n d  u s ag e  permit in the  National La nd Authority [27]. T he stu d y mainly employed SO MA as the b a si c  methodol ogy, but only p e rf orme d Domai n  De co mpo s it ion an d G oal  Service  Mod e ling du ring  th e   identificatio n stage. Servi c e bl uep rintin g wa s u s ed  to descri be the bu sine ss pro c e ss  of the   servi c e. Seve ral mod e ling  notation s  we re use d  in the study: UML’ s  Sequen ce  Di agra m , Service  Comp one nt Specification,   Subsy s tem Dep end enc y  Diag ram,  and  an in stantiati on of th e SO MA  referen c e a r chitecture. WS DL  was  also  use d  for d e scribi ng a nd f o rmali z in g web services,  and  finally a p r oto t ype wa s  dev elope d by  usi ng  WCF  Framework  and  PHP SOAP.  In this case  s t udy,  several co mp onent s of the frame w ork, i.e. t he modeli ng tools, are introdu ce d an d tested.     5.3. Third Ca se Stud y   The  third ca se  study wa s done after  th e  first  draft of  the fram ewo r k  wa s fo rmal ized. T he  ca se  study e m ployed the f u ll pro p o s ed f r ame w o r k i n  applying SOA  approa ch for managi ng da ta  silo s in  the  G o vernm ent St atistical  Agen cy. The  ca se study wa s sta r ted with strat egic  an alysi s  of  the agen cy with BMC and  followe d by a serie s  of BPMN to descri be and to an alyze bu sin e ss  Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM NIKA   ISSN:  1693-6 930     Servi c e Engi neeri ng Ba se d on Service Oriente d  Architecture Met hodol og y   (Su hardi )  1474 pro c e s ses. Due to the focus on the internal a gen cy  process, se rvice bl uep rint ing tool wa s only  use d  lightly  to spe c ify th e data di sse m inati on  se rvice ba se d  on reque st f r om  cu stome r s.  MSOAM was sel e cte d  a s  the SOA  m e thod  and   was  employe d  du ring  the  desi gn  stag e  to  prod uce thre e layers of service: task-centric,  entity-centri c, and  appli c at ion ut ility.  Services and  servi c e co mp osition   is de scribe d  by u s ing   sta nda rd notation.  F i nally, the se rvice i n terfa c e is   descri bed by  usin g WSDL.    5.4. Fourth Case Study   The fo urth  case  stu d y al so  sel e ct s th e Gove rnm e nt Statistical   Agency  a s  t he  study  locu s, but focusin g  on the desi gn of pro posed ex tern al data se rvice for the age ncy. The wo rk  wa s al so  don e by follo win g  the  com p le ted an d fo rm alize d  fra m e w ork. T he  work p r od uced  two  BMC dia g ra ms: a s -i s BM C to d e scrib e existing  sit uation a nd to -be BM C to   prop ose the   new  servi c e. T h e  SWO T  a nal ysis  wa s u s ed b e twe en  the two  BM Cs to  und erstand  the  ex isting  busi n e ss mo del and to va lidate the ne ed for the  propo sed  servi c e in the ag e n cy. Service  blue  printing  an d  BPMN di agra m  were  the n   use d  to  de si g n  bu sin e ss  specifi c ation  o f  the  servi c e.  For  SOA de sign,   MSOAM was empl oyed  wi th Thom as  E r l’s  sta nda rd notation co m p lemente d  wi th   basi c  UM L di agra m s: Use  Ca se, Cla s s Diag ram a nd  Sequen ce  Di agra m .    5.5. Usabilit y  Test  De spite seve ral re quired field adju s tme n ts  and im ple m entation variations, the a doption   attempt on these case  studies  proves t he usability Service Engi neering F r am ewor k. T o  further  test and eval uate the co n c ept s, the propo sed fr a m ewo r k  wa s taught in an IT maste r  de gree  cla s s  f o r  a  se mest e r 1 .  Each   stud ent  the n   assig ned   to perfo rm a ca se study on  an  o r ga nization  by desi gnin g  and d e velo ping a  proto t ype of  tech nology-ena bl ed serv i c es by  adoptin g th e   methodol ogy from the fram ewo r k.        Table 4. Que s tionn aire Structure   Hy pot h e si s Q u e s t i on s  1. Frame w ork is eas y  to compre h end  Q1,  Q5,  Q6   2. Frame w ork is eas y  to ado pt an d implement  Q3,  Q8,  Q9,  Q10 ,  Q11   3. Frame w ork he lps communicate  project  Q2,  Q4   4. Frame w ork is straightfor w a r d   Q7       At the end  o f  the se me ster, a  su rvey  wa s  c ond uct ed to 3 0   stu dents of the  cla s s to  asse ss the v a lue s  a nd  be nefits of  the f r ame w o r k.   T he fo cu s of  the q u e s tionn aire  is to te st the   simpli city of t he fra m e w ork, op eratio na lized  un der  four hypothe ses de sc ribe d  in tabl e 4.  The   respon ds a r e  given unde r 5-scale  li kert  resp ond, from “st r on gly-agr e e ” to “strongly disagre e ”.  The que stion s  and thei r re sults a r e p r e s ented in the followin g  ch art s .                                                                  1)   M a ster  of I n for m atics,   I T  Concen tr ation,  School of  E l ectr i cal  E ngineer ing and I n form atics,   Bandung I n stit ute of T echnolo g y ,   2014.     Evaluation Warning : The document was created with Spire.PDF for Python.
                             ISSN: 16 93-6 930   TELKOM NIKA  Vol. 13, No . 4, Decem b e r  2015 :  146 6 – 1477   1475     Figure 5. Survey Result s o n   Comp re hen sion to the Framework      The re sult s from figure  5 show that mo re  than 80% o f  the resp ond ents ag re e that they  unde rsta nd a nd able to  ad opt the frame w ork. On  th e other h and,  while n o  re sp onde nts p r ovi d e   negative fee dba ck  reg a rding hi s un d e rsta ndin g ,  o n ly about 40 % of resp on dents fe el truly  unde rsta nd t he  role  of e a ch  sta ge  a nd tool s  em ployed i n  th e fram ework.  The  later re sults  provide  a m o tivation to ela borate  the  st age s de scri ption furth e r  an d en rich the  rational fo r ea ch  tool it employed.          Figure 6. Survey Result s o n  Stages Cl arity and Practi cality      Delving  furth e r i n to e a ch  su ccessive  st age  i n  figu re  6,  we  ca n  see the  imp r o v ement  potential s  of  stag es  and  tools  elab oration. All of  re spo nde nt  is a g ree o n  the  cla r ity and   pra c ticality of the identifica t ion stage. Also, 80%  of the re spo nde nt has simil a r opinion for the   desi gn stag e. The rate of agre e me nt among re sp on dents d r op s to 60% for the third (Devel op)  and  fou r th (Deploy) stag e. The re sults  f o r  the   thir d  a nd fou r th  sta ge a r e  rathe r  expect ed d u e  to   the com p lexity of development req u ire d  in the  third  stage, an d the limited form alizatio n defi ned   in the frame w ork fo r the fo urth sta ge. Neverthele s s, these re sult s also  sup port t he motivation  on   further works for  stag e  descriptio n ,  es pec ially for the las t  two s t ages .  In terms  of b enefits of the  prop osed fra m ew o r k, figure 7 sh ows th at more th an  90% of  the respon de nts agree tha t  the  framework  can a c tua lly help an organi zation to introdu ce a n e w  10 % 71% 19% Q1:   I   u nde rs t a n d   th e   con t e x t u a l   fu n c t i o n   of   SE F   Ag ree+ Ag r e e Ne u t r a l Di s a g r e e D i s a g r ee+ 10% 74% 16% Q3 :   I   ca n   u t il iz e   SE F   fo r   my   ow n   con t e x t A g ree+ Ag re e Ne u t r a l Di s a g r e e Di s a g r e e + 3% 42 % 55 % Q5 .   I   un de r s ta nd   th e   fu n c t i o n   of   eac h   st a g e   in   SE F    A g ree+ Ag re e Ne u t r a l Di sa g r e e Di sa g r e e + 42% 58% Q6.   I   un de r s ta nd   th e   fu n c t i o n   of   all   m o de l i ng   too l s   in   SE F A g ree+ Ag re e Ne u t r a l Di s a g r e e D i s a g r ee+ 0% 10 % 20 % 30 % 40 % 50 % 60 % 70 % 80 % 90 % 10 0% 1.   Ide n t i f y 2 .   De s i g n 3.   De v e l o p 4 .   De p l o y Q8 ‐ Q 11:   St a g e   is   Cl e a r   &   Pr a c t i c a l D i s a g r ee+ Di s a g r e e Ne u t r a l Ag r e e Ag r e e+ Evaluation Warning : The document was created with Spire.PDF for Python.