p. 1

issue january 2012 www.servicetechmag.com lviii the service-aware interoperability framework saif making cross-boundary interoperability a first-class citizen by charles n mead runtime governance challenges concerns a practical approach to throttling by roger stoffers agile e-service composition by pouya fatehi seyyed mohsen hashemi $9.99usd $9.69cad 6.99

[close]

p. 2

contents 3 4 18 28 38 from the editor publisher arcitura education inc editor thomas erl copy editor jillian warren communications editor jillian warren supervising production manager ivana lee art director sachie otobuchi contributors pouya fateh seyyed mohsen hashemi charles n mead roger stoffers issue lviii · january 2012 the service-aware interoperability framework making cross-boundary interoperability a first-class citizen by charles n mead chair of the hl7 architecture board runtime governance challenges concerns a practical approach to throttling by roger stoffers solution architect hewlett packard in the netherlands agile e-service composition by pouya fateh software designer iran rayaneh company · seyyed mohsen hashemi faculty member at science and research branch azad university tehran contributors copyright © arcitura education inc 2 www.servicetechmag.com

[close]

p. 3

from the editor issue lviii · january 2012 in conjunction with the new books being released in 2012 this year marks the launch of the cloud computing design patterns catalog project as with the soa design patterns initiative that was carried out a few years ago this effort will rely heavily on community involvement for both contribution and review a dedicated cloudpatterns.org site is in development based on the established soapatterns.org site that serves as both an online reference for ratified patterns as well as a medium for the submission and review of candidate patterns it is interesting how we need to approach the documentation of cloud computing patterns in a different light than we did with soa and service-orientation the focus is naturally more of a mechanical nature when compared to some of the business-centric objectives that had to be taken into account with the strategic objectives of soa cloud computing patterns will be based on the numerous moving parts that comprise cloud environments as well as the formal practices that guide their application and evolution if you are interested in learning more about contributing contact info@arcitura.com thomas erl series editor and site editor copyright © arcitura education inc 3 www.servicetechmag.com

[close]

p. 4

issue lviii · january 2012 the service-aware interoperability framework making cross-boundary interoperability a first-class citizen by charles n mead chair of the hl7 architecture board abstract the hl7 architecture board hl7 arb has just released the specification of the canonical definition of the service-aware interoperability framework saif cd the document defines a set of languages that enable component developers working in any one of the established enterprise architecture frameworks ­ togaf zachman rm-dop etc ­ to more consistently and explicitly define appropriate details of a given component a service a message a document etc that is involved in one or more cross-boundary intra or inter-enterprise interoperability scenarios specifically the saif cd defines a set of languages for describing informational static and behavioral dynamic semantics from the perspective of interoperability the various languages are ultimately instantiated in organization-specific saif implementation guides igs as such the saif cd and its derivative igs are not meant to be replacements but rather adjuncts for existing architecture frameworks in addition to the informational and behavioral languages the saif cd provides a framework for collecting various artifacts based on applying its languages across multiple dimensions viewed from several role-based perspectives at its core the saif cd draws heavily on a number of the soa design principles and the soa benefits and goals of thomas erl s previous publications finally it provides a governance language that is based on the soa governance framework defined in erl s recent book on soa governance [ref-1 the video presentation that accompanies this transcript can be found at the arcitura youtube channel www youtube.com/arcitura as follows video part 1 http www.youtube.com/watch?v=k7bamuibfe4 video part 2 http www.youtube.com/watch?v=xtfiesprhtu video part 3 http www.youtube.com/watch?v=1uqqya55_pm video part 4 http www.youtube.com/watch?v=rklorddgwke the following is a complete transcription of these video recordings introduction so hello to everyone my name is charlie mead i am the chair of the hl7 or health level seven architecture board [ref-2 and i m here to talk a little bit today about the service aware interoperability framework ­ or as we call it saif ­ and in particular what i m going to be talking about today as we move forward is the canonical definition of what saif really is and about what happens to that canonical definition as it is instantiated in particular organizations first i probably need to give a little bit of background hl7 is an international standards development organization sdo that you can probably tell from the name has to do with health care interoperability but saif actually has nothing to do with health care it has to do with interoperability in particular saif is a framework for talking about interoperability across enterprises so not only intraenterprise but also inter-enterprise the whole motivation for saif was the notion that enterprise architecture framework per se ­ so zachman togaf or rm-odp or other enterprise architectural framework ­ don t a priori make interoperability in particular cross-enterprise interoperability a first-class citizen the fact that this work came out of hl7 is really simply because health care interoperability is a very very big and important copyright © arcitura education inc 4 www.servicetechmag.com

[close]

p. 5

issue lviii · january 2012 issue for hl7 members and their stakeholders however there are two urls which i hope will be supplied by this discussion and those two urls are interesting in the sense that they point to two organizations hl7 architecture board being one the oasis [ref-3 service-oriented architecture group being the other as it turns out they were working in parallel on very similar aspects of interoperability and though our ­ hl7 s service-aware interoperability framework saif canonical definition [ref-4 which is what i m talking about today ­ is certainly not identical to their reference architecture foundation for service-oriented architecture there are striking similarities we are now co-referencing our documents because we both believe that when two organizations come to pretty much similar conclusions independently that s worth noting so with that in mind we will start to go through the slides there are a fair number of slides so i will go through some very quickly and some other ones i will spend a little bit more time on assuming that you will have access to the slides for examination at your leisure should you so desire why interoperability is hard so first let s talk about why interoperability is hard i m sure everyone listening to this or at least most people listening to this have had experience with integrating systems across boundaries and as the kind of interoperability you re trying to achieve becomes increasingly complicated the difficulty of making the interoperability actually happen turns out to be increasingly difficult i think if you had to summarize at a high level why is interoperability hard these two bullets at least do a reasonably good job of pointing out some of the major issues as you cross different boundaries there are different levels of understanding and different kinds of things that need to be understood ­ and certainly some types of interoperability are harder than others and that has to do with whether you want computable semantics or if you just want syntax secondly you must understand the breadth of the deployment context ­ exactly what are you interoperating across in the end we re talking about managing complexity and i think if you look at a particular interoperability scenario and you ask why did this interoperability scenario fail ­ again not every scenario fails for the same reason ­ there usually is at least one or two of these three points the first point ­ the fact that there are no common technology standards ­ is probably the least important actually while the next two are more important i.e that implicit assumptions that occur at multiple levels of the discretion don t get made explicit until it gets out on the wire at runtime and of course everything s made explicit at runtime and then also there are not a lot of formals ways to coordinate communication and explicitness between levels of stakeholders because of course stakeholders have very very different views all the way from high level business use down to developer or tester mechanics the view that i use and have used for quite some time about how to describe a complex system ­ because i think interoperability by definition involves a complex system or defines a complex system ­ is actually a view that i got from a book from a long time ago in 1994 by ivar jacobson he doesn t have this exact picture or he doesn t describe it exactly this way but i give him full credit for this view of complexity i.e that a complex system is one that by definition has multiple levels of vertical organization and in order to produce whatever the product of value that that the complex system needs to produce there are processes that by definition cross these vertical boundaries and of course health care or health care it and the interoperability that is involved is a complex system recall however that i said at the beginning that the saif cd has nothing to do with health care it per se there are many other contexts where interoperability is important and if the context involves multiple levels of vertical organization with processes that need to interoperate across multiple boundaries then it is by definition a complex system copyright © arcitura education inc 5 www.servicetechmag.com

[close]

p. 6

issue lviii · january 2012 interoperability in health care this is the only health care specific slide in the talk and it is really just to point out the kind of interoperability scenarios that people in health care clinical trials and life sciences worry about and in general you can assume that any of these stakeholders can and does need to interoperate between or within the other ones so you ve got a fair number of possible connections of points defining and describing complex systems so if you have a complex system we agree that an interoperability scenario or a set of interoperability scenarios exist and of course if you think about thomas erl s soa design principles and you think about intrinsic interoperability as a derivative or result of the application of the design principles intrinsic interoperability meaning we don t want to have one-off integration scenarios i.e we want to actually have intrinsic interoperability that comes from well architected services then we have to say well if we ve got a complex system how do we actually define and describe that complex system it turns out that there is actually a fair amount of knowledge about how to go about doing that ­ not necessarily linked to software per se ­ but the examples i ve given on the slide of course are the ones i mentioned before that are enterprise architecture frameworks that do have to do with defining complexity and basically the general approach to defining complexity or a complex system is that it has different dimensions and it has different perspectives you will see as we move forward here that saif is really just an explicit definition of some dimensions and an explicit definition of perspectives with rules on how to make those different dimensions and different perspectives explicit in the various cells if you will we ll talk about an actual intersection device that pulls all of that stuff together interoperability specification matrix there is a core construct in saif called the interoperability specification matrix the interoperability specification matrix is ­ as the slide says ­ a container of artifacts and collectively specified systems components so in saif the dimensions were chosen to use rm-odp viewpoints for those of you familiar with rm-odp viewpoints that probably makes perfect sense to you but if you re not familiar with rm-odp viewpoints it s not actually critical the point is to use dimensions and intersect them with perspectives and we ll talk a little bit further down the road here on what the actual dimensions and perspectives in saif are i think the important lesson from this slide is that a interoperability across enterprise boundaries is a complex system in and of itself and that b to define or describe a complex system we need to worry about intersecting dimensions with perspectives saif semantics and frameworks now in saif we think about two kinds of semantics ­ informational or static semantics and behavioral or dynamic semantics ­ and what you ll see as we move forward is that we have both types of semantics represented as part of a specific dimension and specific perspective in the saif cd canonical definition there are actually four frameworks the first one and the one which we would argue from the overall perspective of the architecture coordinates all of the other frameworks and is therefore the single most important one is the governance framework the way that thomas erl and i came to discuss saif and all that surrounds saif is that i was privileged to be a reviewer on his just-published extremely good soa governance book in the course of doing that i became very much a believer in his governance framework which we ll of course talk about later in this discussion that governance framework is the basis for the governance framework of saif there are some other aspects about saif that go beyond copyright © arcitura education inc 6 www.servicetechmag.com

[close]

p. 7

issue lviii · january 2012 thomas governance framework for reasons that i hope you ll come to understand but the core construct and the core language to describe governance in the saif governance framework is taken from thomas erl s recent governance text book in addition there are three other frameworks there is a behavioral framework bf that defines the language needed to specify behavioral semantics so things like contracts goals operations processes etc there s an information framework if that is for defining static semantics including information models data types classes attributes relationships value sets etc and then there s a final framework called the enterprise consistency and conformity framework eccf which is associated with the interoperability specification matrix and that defines the language that s needed to really specify different component artifacts and talk about the relationships between them part 2 of the youtube presentation begins here understanding the essence of interoperability shared purpose the essence of interoperability is not actually technical and i think one of the things that saif cd really emphasizes is that technical considerations of interoperability should really follow business-level considerations of shared purpose and in that sense you probably noticed i didn t comment on it but the fact that saif stands for service-aware interoperability framework it s not soa in particular it s certainly heavily influenced by soa and certainly can be implemented i would argue most successfully in an soa environment but in the health care world there s a lot of interoperability that s based on messages and documents not on services per se at least at this point in time november/december 2011 but the notion that drives interoperability ­ or that should drive interoperability ­ is shared purpose i have in this slide deck a number of concept maps which i m not going to talk through in detail because you have the slides and the video to look at the concept maps however i do want to emphasize the concept of shared purpose because shared purpose at a human level or at an organization level is ultimately manifested in interoperability at a technical level in an attempt ­ hopefully a successful attempt ­ to realize the goals of the shared purposes applying interoperability to diverse scenarios i alluded to earlier but i want to emphasize a little more at this point in time is this notion that not all interoperability scenarios are created equal they re not all equally difficult this is a sort of a rough approximation graph taken from the national cancer institute in the national institute of health where i work and it basically points out that there are pretty much two dimensions to interoperability and i say pretty much because i think there s an almost third dimension which i ll mention after i walk through this graphic the two dimensions are the interoperability type and the deployment context now by interoperability type i mean everything from human-to-human interoperability which is fairly straight forward to syntactic interoperability ­ so something like web browser based interoperability ­ to computational semantic interoperability which is of course the hardest because then you re talking about having semantics that are both explicitly specified and computable and they can be either static semantic common data or metadata structures or they can be behavioral semantics there are more and more interesting opportunities for applying for instance rdf tuple/triple-based expressions of service interfaces for runtime computation of dynamics the point is that there are multiple and different kinds of interoperability types and any particular shared purpose scenario have to define what its interoperability type may be in addition there s this notion of deployment context and clearly the deployment context in part determines how difficult an interoperability scenario will be so for any given interoperability type the larger the context of deployment ­ as you go from copyright © arcitura education inc 7 www.servicetechmag.com

[close]

p. 8

issue lviii · january 2012 single department to an organization to cross organization to across the enterprise to cross enterprise to cross multiple enterprises ­ the details the devil is in the details and the difficulty of interoperability in terms of a particular scenario becomes greater and greater the third dimension now i mentioned that there s sort of a third dimension to this ­ and i don t know if it qualifies as a full third dimension but i think it s worth mentioning ­ and that is that if the interoperability scenario ­ no matter what the deployment context ­ it is really devoted to information integration it s mostly about static semantics and integrating static semantics that s probably easier than an interoperability scenario ­ in particular a computational one ­ in which you want some kind of behavioral-based application or service component integration those are obviously the hardest interoperability scenarios but the purpose of this slide is to point out that not all interoperability scenarios are the same not all are as difficult and the saif cd basically doesn t say that you have to do everything but it does say here are the tools you need to do what you need to do depending on the complexity or difficulty of the problem you re addressing so for simple interoperability scenarios you specify a lot less than you do for a more complex interoperability scenario the saif cd is meant to provide the language necessary to describe explicitly interoperability scenarios of any level of complexity this is meant to give you a sort of cartoonish view of the fact that interoperability is always difficult but the more you can agree on the better you can do in terms of interoperability remember i mentioned saif was formed around the notion that dimensions intersect with perspectives the three perspectives in saif are ­ not surprisingly ­ called the conceptual logical and the implementable perspectives ­ not to be confused with omg s mda levels because the saif perspectives are role based perspectives not necessarily software engineering constructs clearly the more you can agree on the details at the conceptual logical and implementable levels the easier it gets to interoperate and this diagram is meant to show that if you have one person who agrees on the conceptual perspective and another one who has details all the way down to the implementable perspective then the interoperability scenario is going to require more negotiation than if you have two people who have used the same framework all the way down to the implementable level it s always necessary to align expectations and assumptions in order to achieve interoperability it s just a question of how difficult that alignment will be the point is that by using the same framework from the beginning to describe complexity you ve got the same basic language in place that does make explicit discussion easier to have saif in more detail here is an overview of what saif is in a little bit more detail it s the intersection of this notion of computable semantic interoperability software engineering processes that s where we get our perspectives from the viewpoints of rm-odp as the saif dimensions we could have used the viewpoints from zachman or togaf but we chose rm-odp because we are a standards organization and we work a lot with iso and rmodp is an iso standard and then we have as i mentioned fairly significant and deep influences from soa and particularly thomas erl s work ­ the design principles the governance framework etc and then it s all ultimately contextualized with this notion of shared purpose i don t think for this audience that i very much need to go through what soa or service-oriented architecture is about this slide is really just to show what kinds of things saif carries with it from the world of soa and in particular it s about the notion of behavior contracts consistency separation of concerns and of course as i mentioned the governance framework it s important when you talk about dimensions versus perspectives with saif that you recognize that the perspective is really a notion about roles it s about different roles in the copyright © arcitura education inc 8 www.servicetechmag.com

[close]

p. 9

issue lviii · january 2012 same dimension have different perspectives and therefore they express different things in different explicit ways and what saif is really trying to do is to provide language for each of those perspectives and for each of those dimensions saif versus rm-opd these are the pillars of computable semantic interoperability and i m not going to spend very much time on them because i figure that people who are really interested in them can either read through these or there are some written in the literature about these four pillars the point is that if you look at these pillars each of them is about a certain level of explicitness now rm-odp for those of you don t know about rm-odp is an iso standard ­ and you see the iso standard number at the top there called viewpoints ­ around which to build enterprise architecture there s a new book on rm-odp it s actually getting a lot of traction recently there are uml templates for rm-odp and several of the large health care organizations outside of the united states are now using rm-odp saif is not just rm-odp however saif drew on rm-odp for two things it s dimensions and for certain well-defined terms particularly for the behavioral framework so if you know about rm-odp saif will be second nature if you don t know about rm-odp you should know that in fact you can take saif and apply it in non-rmodp environments very easily in canada the national health program it s called canada infoway is mapping saif with togaf and the department of defense in the united states is using saif integrated with dodaf which is their dod version of togaf so here are the five dimensions of rmodp and if you know zachman then you ll see they sort of look like zachman ­ unlike zachman they re not fully orthogonal but they serve the purpose and as we talk about the interoperability specification matrix a little later in the presentation i think the important message is to be explicit about dimensions and perspectives it doesn t actually matter where you put a particular artifact as long as you re explicit about it and consistent about it a deeper look at shared purpose and then as i come back to again shared purpose shared purpose is the fundamental driver and in some sense the linkage between business level expectations and on-the-wire explicit interoperability scenarios it is really very similar to ­ and in some sense identical with ­ one of the seven benefits that thomas erl mentions in the benefits and goals of soa which is tighter business-technology alignment ultimately the shared purpose at the business level has to be able to be manifested at the technical level as a successful interoperability scenario here s a concept map of the overview of the saif cd canonical definition and you ll see that it defines languages which support shared purpose semantics you see the governance semantics behavioral semantics information semantics as well as consistency and conformity semantics the colors are meant to mean the following blue or turquoise are meant to be things that are specifically defined in the saif cd yellow are things that are defined specifically in saif implementation guides the notion of a saif canonical definition is that there is one saif canonical definition and there are multiple saif implementation guides igs each consistent with ­ but not identical to ­ the saif cd the green concepts are concepts outside the domain of the ig i.e about the actual operational implementation the instantiation of an implementation guide within an organization and then the rust color or earth color or terra cotta ­ however it shows on your screen ­ are really standards that saif drew on in particular you see there the rm-odp as well as another important paper that really looked at rm-odp and said rmodp needs context and that in fact copyright © arcitura education inc 9 www.servicetechmag.com

[close]

p. 10

issue lviii · january 2012 is what saif has brought by its use of perspectives connectedness of languages in saif and governance here is a concept map about the interrelationships between the languages in saif so remember i said there were four languages a governance language a behavioral language an informational language and there s a consistency and conformity language and the important thing about those languages is that they are related in some very specific kinds of ways which are specified on this content map i think the most important aspect of this is the role that governance plays and remember i said there were aspects of saif governance that are not explicitly talked about in thomas erl s book although there s nothing contradictory in thomas erl s book to anything on this slide or anything in saif but in particular the governance framework has language to talk about artifact governance and it also has language to talk about community governance because ultimately when you cross enterprise boundaries you are talking about community participation and ultimately therefore community governance part 3 of the youtube presentation begins here this a very high level view from open group of governance that certainly its consistent with thomas view of the world i m going to go through a series of slides here ­ if you don t know thomas view of the world of governance i would strongly encourage you to go out and invest in the book it s an excellent book the next several slides really take that very very high level notion of governance and push it down aligning it with thomas erl s book simply because we ­ at hl7 within the architecture board and technical steering committee ­ think that it is a very good framework we actually think it is not unique to soa at all but one which we we re able to adapt very successfully to the saif cd i probably don t need to read through definitions of what governance is but i want to emphasize ­ on what is governance 2 slide ­ is governance is an overarching set of policies about how decisions are made how management is done how methodology is executed ­ in particular governance and methodology and management need to be separated and that s probably the most important aspect which is shown on what is governance not i think that it s been very instructive to hl7 to really dig into the details ­ thanks to thomas book ­ of separating out management methodology and governance and i would say irrespective of whether you choose to adopt some or all of saif and whether you choose to indulge or invest yourself in trying to understand cross-enterprise interoperability that the importance of governance and the importance of separating governance from management and methodology is essential no matter what it is you re trying to govern ­ whether it s it whether it s soa or whether it s just an organization okay so i m now up to the slide that says saif cd languages and i m emphasizing again that the governance language ­ the governance framework contains language about governance the behavioral framework that contains language about behavioral semantics it s very important to note that the governance framework also has language about behavior but its behavior is at an organizational level whereas the behavioral framework is really behavior at the technical level so it really focuses on what s happening at the interface so there is some overlap between the behavioral framework terms which are specified in large part by rm-odp and the governance framework terms that have to do with behavior that are specified to some degree in thomas s book and other degrees by the actual saif cd by members of the hl7 architecture board and then finally the eccf the enterprise consistency and conformity framework contains language that at the present scopes just to artifact governance copyright © arcitura education inc 10 www.servicetechmag.com

[close]

p. 11

issue lviii · january 2012 governance framework in detail so now we re going to talk about the governance framework in a little bit more depth for those of you that are familiar with thomas erl s soa governance book this will be absolute repetition because as i said at the beginning the saif cd has taken the basic framework that thomas and his coauthors describe in the soa governance book and essentially said this is the language and this is the way we need to talk about at least certain aspects of governance so those of you not familiar the basic framework ­ what i call a governance vector although that s my term not thomas ­ defines governance vector which consists of a four-tuple of precepts people processes and metrics if you drill down the precepts component it has its own four-tuple of objectives policies standards and guidelines in my experience in implementing a governance framework both in my job at the national cancer institute and then working with hl7 in the architecture board this actually is one of the most important aspects of the governance framework that thomas erl proposed or defined in his book because it actually gives you a very concrete way to say here is what i m trying to accomplish at this point in my governance governance should be about at least in the beginning and i would argue always is what am i going to govern you can t govern everything at once we must consider how can i start without first of all freaking everybody out like some heavy-handed monster that s going to come in the door and second of all how can i really actually understand this governance is working how do i know it s making any sense and the way that both thomas erl s text and the saif cd address the notion of governance or how to govern or where to govern or what to govern is governance should be intersected with risk management so you apply governance vectors to specific points along your risk matrix and this notion that a precept has an objective and associated policies ­ often organizational policies or constraints standards that you want to apply or guidelines that you d have liked to have considered ­ is a perfect concrete way to say okay these are actually how i m going to get my arms into the risk management that i m trying to accomplish by doing governance at this point in my product development then we have people ­ or people in roles ­ processes and metrics i want to emphasize that the processes we re talking about here are not the processes that generate the things that are being governed these are the governance processes themselves and if you invest in the governance book you ll see very well done associated precepts processes and people and then of course metrics are the way you quantitatively assess whether you ve accomplished a particular precept so here is the concept map of the governance framework along with the language and you ll notice over in the lower left-hand corner you see precepts you see people roles processes and metrics and then farther to the right you see a bunch of other things called terms of art those are additional terms that the saif cd finds from the perspective of cross-enterprise interoperability that are not explicitly covered in thomas book in the context of governance but certainly if you look at those terms many of them come right out of soa or are completely relevant to an soa environment as i said before i think that the tremendous value of thomas erl s book is that although it s very useful in the world of soa governance i don t think it s unique to soa it has much more applicability than just soa saif constructs and frameworks now there are a few core constructs in saif and i ve mentioned most of them i ve mentioned thomas erl s governance framework i ve mentioned rm-odp i ve mentioned the notion of software engineering roles ­ architects at the ontological level domain experts at the conceptual level and developers being at the implementable level another core construct of saif that really does help us define in really explicit terms how we deal with shared purpose and that is martin fowler s accountability pattern copyright © arcitura education inc 11 www.servicetechmag.com

[close]

p. 12

issue lviii · january 2012 martin fowler s accountability pattern another important aspect of the saif canonical definition specification is martin fowler s accountability pattern this accountability pattern which martin fowler published probably twenty years ago now is very good about specifying the notion of in any particular context where you have accountability you ve got a commissioning party and a responsible party now ultimately of course that is exactly what happens at a service interface but it also turns out to be a good way to think about shared purpose at the business level so the saif cd really does take this notion of a responsible party and a commissioning party and the associated accountability that goes with it and starts to be explicit about it at the conceptual level ­ the business shared purpose level if you would ­ and then drives that all the way down through the logical level through the implementable level all the way down to testable implementations behavioral framework here are a quick couple of slides on the behavioral framework and the core constructs of the behavioral framework which grow out of that martin fowler kind of accountability pattern and in particular have to do with services operations and roles and again i m not going to talk to you about the concept maps in detail because i m going to assume you have the concept maps to look at and you can look at them as much as you d like this is the concept map around contracts and you ll see that contracts are constrained by policies and you have to realize the objective of community that s true of a contract whether it s a technical contract or whether it s a shared purpose business level contract you ll also notice the notion of policies and remember that policy is the second part of the four-tuple that defines a precept with precept being one of the four-tuple that defines a governance point or a governance vector so you see how the basic notion of governance is sitting throughout the saif cd and in fact it is very consistent that it is inspired by much of the work from thomas erl s soa governance book copyright © arcitura education inc 12 www.servicetechmag.com

[close]

p. 13

issue lviii · january 2012 figure 1 governance is often applied to mitigate risk the gf defines the language to specify governance vectors based on the framework presented in thomas erl s soa governance book part 4 of the youtube presentation begins here here s the behavioral framework concept map of operations preconditions post conditions etc remember i said that the behavioral framework was restricting its governance and its definitional language to technical governance so we re talking about governance at an interface and of course this stuff naturally manifests itself in an soa-based implementation and then finally behavioral framework processes all of these are ­ remember the saif cd is a set of languages ­terms and relationships that are very explicitly defined in the saif cd and then here remember i showed you this slide before if you think about this it has to do with a certain level of difficulty in realizing an interoperability scenario now i would say again it s the degree of realizing the particular interoperability scenario scoped in a particular set of contracts that define roles operations and processes so that s really if you think about thomas goals and benefits of soa number one ­ intrinsic interoperability this is another view the saif-based view of intrinsic interoperability okay now i said that there was some overlap between the behavioral framework and the governance framework this is a picture of that overlap the terms in bold are terms that are used in both languages ­ both the behavioral framework language and the governance framework language and again i don t want to go through this in detail because you all have the document or you have the slides and then also the saif document is openly available copyright © arcitura education inc 13 www.servicetechmag.com

[close]

p. 14

issue lviii · january 2012 information framework now the information framework the information framework is probably a framework that is more well-defined in health care than most other places because much of the data that flows around health care is static data ­ patient data or research data or clinical trial data and i think that for most people the notion of information modeling is probably something that everybody knows a lot about but it s probably not been carried at least in many domains to the degree it has been in health care but you won t see anything in here that you wouldn t recognize if you had done information modeling including codes classes attributes data type data type bindings multiplicity value sets those sorts of things enterprise consistency and conformity framework okay now we come to the enterprise consistency and conformity framework and i want to just comment briefly on the choice of the words consistency and conformity they re taken from iso very specifically and they are meant to disambiguate once and for all the difference between conformity compliance coordination consistency ­ all of those words that we throw around and we sort of know what we mean but nobody ever quite means exactly the same thing these terms are formally defined in saif but actually we re just using the formal iso definitions this is the concept map of the eccf ­ the enterprise consistency and conformity framework and probably the most important piece of this slide ­ remember blue is what s defined in the saif cd ­ are the terms of art including province traceability localization compatibility consistency correspondence conformance and compliance the most important point to know is that those terms define how we navigate between artifacts or artifact definitions because remember now you ve got a single saif canonical definition and the various languages it defines that allow you to define multiple implementations guides and those implementation guides specify the content and representation details of specific artifacts and then you ve got actual artifacts that are developed using those rules in the implementation guide so on this slide the blue is saif which would be the definitions the yellow is the implementation guide and then the purple are the things that actually get specified i.e the artifact instances interoperability specification matrix and artifacts now how do those actual artifacts get defined they get defined in the implementation guide and the implementation guide is defined using the saif cd and they re all collected in something called the interoperability specification matrix and the interoperability specification matrix is in fact the physical matrix that resolves from the intersection of dimensions ­ rm-odp viewpoints ­ and perspectives ­ software engineering roles if you will this is the relationship that i just mentioned of the saif cd on the top there is a type definition and then you ve got multiple implementation guides ­ potentially multiple implementation guides there are now four saif implementation guides that are being either fully developed have been fully developed or are being developed they are not at all identical but they are all using the saif cd as their root and then once that implementation guide is defined ­ so it defines the artifacts that you need to specify ­ it defines the content and representation of different artifacts for different dimensions and for different perspectives then you actually have artifacts that s the set of interoperability specification instances and then from those artifacts you actually build things you actually build actual code and that s the purpose of the saif cd in the first place conformance compliance consistency traceability and compatibility so here s the walk through an interoperability specification matrix at the level of the saif cd all that s specified is basically the semantics of the column names and the row names that s what s specified in the copyright © arcitura education inc 14 www.servicetechmag.com

[close]

p. 15

issue lviii · january 2012 saif cd a saif implementation guide specifies what s called an interoperability specification template ­ not the interoperability specification matrix itself but an organization-specific instance of it ­ and it actually says here are the things that we think in our organization is going to need to define explicitly for the host of interoperability scenarios we can have realizing that not every interoperability scenario has the same level of specification requirements here are the relationships that the eccf defines so there are conformance statements that are a very important part of saif in the end what you want is ­ i said this in the very beginning now i m making a point to repeat it ­ the number one enemy of successful interoperability is lack of explicitness and what saif does is basically provide a mechanism for making explicit conformance statements at any level ­ conceptual logical or implementable ­ that are ultimately then asserted by pair-wise conformance assertions in an implementation so a conformance statement at the implementable level can be a computable conformance statement it can be tested automatically at the logical level it may be able to be tested automatically at the conceptual level it might not be able to be tested automatically but it should be testable and verifiable in a boolean sense as to whether or not the implementation was successfully able to fulfill that conformance statement so conformance statements made in a specification and conformance assertions made in an implementation are essentially bound together pair-wise and then you can measure conformance conformance is linked only to the relationship between an implementation and an instance and a specification all the other relationships have to do with how you relate different artifacts to each other so there is the notion of compliance a compliant artifact is usually one that has some sort of restriction on another artifact ­ so you see the arrow there source and target ­ as you move up and down either across the rows or up and down the columns you re always worried about compliant movement not conformant movement then you see a few other terms e.g consistency ­ so that would mean for instance that if you specified some static semantics in your informational perspective or your informational dimension that you would want those same semantics to be consistent across the other dimensions that showed up so that if you had behavior showing up in the computational dimension you would want the static structures moved around by say an activity diagram to be consistent with the information structures defined in the informational dimension traceability everybody knows about traceability becomes much more of a challenge and also much more valuable when you realize what you re tracing is tracing explicit statements that are going to support conformity assessments and finally there is the notion of compatibility which has largely to do with making sure that localization of value sets data type restrictions etc are consistent across the interoperability scenario here s a picture of the description that i just gave of the notion of pair wise conformance statements and conformance assertions conformance statements can be made at any level and ultimately when you have an implementation instance they are paired with conformance assertions to assess conformity of an implementation instance conclusion so in summary what is the saif cd about saif is about interoperability and the reason it is important for people in the soa community to hear a little bit about saif is that saif really does bring interoperability up to the level of first-class citizen in an enterprise architecture which is of course one of the goals of soa and what the saif cd is doing is providing a set of languages for specifying the various aspects of components that ultimately affect their interoperability saif is not enterprise architecture it is not meant to replace rmodp to replace togaf to replace zachman it is meant to be used as an adjunct in any of those or any other enterprise architecture framework or approaches that one may have it basically focuses on and concentrates copyright © arcitura education inc 15 www.servicetechmag.com

[close]