Na począ­tek pod­su­mo­wa­nie cyto­wa­ne­go artykułu:

BABOK 2.0 sets up a fra­me­work for the requ­ire­ments deve­lop­ment and mana­ge­ment, which seems to appe­ar as a stan­dard used by many orga­ni­za­tions aro­und the world. Between TOGAF 9 and BABOK 2.0, the­re is almost 1:1 cor­re­spon­den­ce but the­re may be more deta­ils and acti­vi­ties in the first one. TOGAF is a metho­do­lo­gy whe­re­as the BABOK is metho­do­lo­gy agno­stic, so it can be tric­ky to trans­la­te betwe­en the two but nothing pre­vent an Enterprise Architecture team to use this ana­lo­go­us technique.

If an orga­ni­za­tion fol­lows the TOGAF metho­do­lo­gy and Business Analysts use BABOK, the later will pro­vi­de a lot of use­ful infor­ma­tion, as a refe­ren­ce; BABOK won’t give you direc­tion for an Enterprise Architecture.

Sources: Chapter 4 IIBA?s BABOK 2.0, TOGAF 9 (źr. Managing Requirements from a Business Analyst or an Enterprise Architect per­spec­ti­ve using BABOK 2.0 and/or TOGAF 9.)

W kil­ku zda­niach. Diagram poni­żej obra­zu­je dwa róż­ne spoj­rze­nia na ​„to samo”:

Autor arty­ku­łu porów­nu­je obie te spe­cy­fi­ka­cje i poka­zu­je, że są prak­tycz­nie zgod­ne w 100%, nie licząc meto­dy pre­zen­ta­cji i per­spek­ty­wy. W obu przy­pad­kach ma miej­sce ana­li­za, porów­na­nie i spe­cy­fi­ka­cja celów biz­ne­so­wych oraz przy­po­rząd­ko­wa­nie ich do narzę­dzi (głów­nie ale nie tyl­ko IT) wspie­ra­ją­cych reali­za­cję tego celu. Jeżeli uznać, że spe­cy­fi­ka­cja coś opi­su­je, to zależ­nie od fazy pro­jek­tu jest spe­cy­fi­ka­cją potrzeb a potem spe­cy­fi­ka­cją tego co się posia­da (jak uda się zakup ;)).