Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. GEAO news The magazine of the Global Enterprise Architecture Organisation JAnuAry / FEBruAry 2006 » Back to the basics of Architecture » Enterprise Architecture as a corporate competency » From Service Oriented Architecture to Service Oriented Enterprise
  2. 2. Contents GEAO news The magazine of the Global Enterprise Architecture Organisation JANUARY / FEBRUARY 2006 GEAO news » Back to the basics of Architecture » Enterprise Architecture as a corporate competency » From Service Oriented Architecture to Service Oriented Enterprise Contents Editorial managing Editor EA Insight - Back to Basics 3 Damian Woodhouse (acting) e-mail: Membership - news in brief 5 dEsign & Layout GEAO Publishing Article series part 2 - subscription GEAO members receive this newsletter Enterprise Architecture as a automatically as part of their member- Corporate Competency 6 ship. Back issues can be downloaded from the GEAO website. Article - mEmbErship Details of Membership of the GEAO From Service Oriented Architecture to can be found on the GEAO website at Service Oriented Enterprise 10 pubLishing GEAO News is owned and published bi-monthly by the Global Enterprise Architecture Organisation. advErtising saLEs e-mail: Any facts stated or opinions expressed in this newsletter are the sole respon- sibility of the contributor. Neither the Global Enterprise Architecture Organi- sation, the Editor nor the Publishers can be held responsible for any injury or loss sustained in reliance thereon. © GEAO 2006 GEAO news January/February 006
  3. 3. EA Insight Back to Basics by mark perry Having had a busy 2005, the Christmas/new year break was a good time for some reflection on the various architecture initiatives and pro- grammes I have been involved in over the last year. One repeating conclusion was how easy it is to become caught up in the detail of an interesting technical discussion or a particularly juicy design topic and forget the underlying basics which help make architecture a reality, and the teams responsible for it effective. Even though many architecture teams, particularly the larger more established ones, will have people focused on the quality management aspects of design and governance, I thought it worthwhile to share my thoughts on the basics which all good architecture teams and their members should never loose sight off. the process skilled people and supporting tools, to take the analysis and definition of process into Mark Perry is an Enterprise Architect How many times of you been involved the working detail and to ensure people with EDS UK. He has a background in work around processes only to see are managed against it. However, we in architecture and strategy, consult- the result become a complicated web of should all look to remember and promote relationship structures, process models these core process steps. Being able to ing, systems engineering and technical and dependency definitions which quickly differentiate those activities associated management across a wide variety of become incomprehensible to anyone but with (1) the capture and understanding industries - these include government, those involved in the original process of requirements and (2) those associated defence, retail, insurance, shipping, analysis and definition? This need not with the assessment of options and the logistics/supply chain, pharmaceuticals happen if we keep the perspective at the design of solutions cannot be emphasised and energy/utilities. He is a Chartered right level. Think about the basic steps enough – yet I still see people getting the Engineer (Engineering Council) and a which we all recognise in the formulation two areas confused with the correspond- Member of the Institution of Electrical of any solution – be it an architectural ing ‘fall out’. framework or a system design. There Engineers in the UK. He has a BSc in are requirements which need capturing Electrical and Electronic Engineering and clarifying, there are options which the product (Bath, UK) and an MSc in Systems need identifying and assessing, and there Engineering (Surrey, UK). There is always a lot of debate about the are design decisions to be taken and output from an architecture group and, to Email: communicated. Even if we were able to be quite honest, a lot of it really looses the remember just these three absolutely core essence of what we are trying to commu- steps, and make them evident in our roles nicate as architects. Again, going back to and in the production of the supporting basics it really should not be too difficult to documentation, things would become just capture key statements about the clients that much clearer for all those involved. strategy goals, their current business and This clarity is even more important in an operating environment, the organisation Enterprise Architecture sense because of structure and geographic locations, their the environment coverage and audience current IS/IT deployment and standards, diversity which has to be addressed when and finally the specific topics/problems communicating architectural process and which need solving. In other words think outcomes. about those things which provide the We will always need the appropriately context. GEAO news January/February 006
  4. 4. EA Insight A clear documentation structure and There will always be cases where the user simple but enforced version control can go operating environment and client solu- a long way in ensuring the teams involved tions to be progressed need sophisticated stay focused on the core client objectives analysis and design methodologies and and constraints. Sophisticated require- tooling (even more when you consider the ments management processes and tooling ongoing task of system change manage- can provide real additional benefits but ment and the associated impact/risk even these won’t get you very far if the assessment needed). Often there are real basics aren’t in place. advantages to spending some time think- ing about what it is you actually want to Design models are always good for a have as documented architecture output heated debate. Should you use this archi- to share with both clients and your internal tectural framework and methodology or teams. Also think about the key architec- that model standard and supporting tool. tural principles and decisions and how you Once again – ask yourself what are we might want to document and communicate trying to communicate and to who as we them, e.g.: go through the design process. • Off-the-shelf v. bespoke v. composite. First - think of the solution concept – what users need to access the solution, where • Structured and inspectable assess- are they roughly, what information do they ment and selection of products. need, how do they/could they operate • Strategies for reducing technology (e.g. office, mobile, etc), what availabil- diversity. ity do they require. At this level readily • Intercepting and influencing of delivery available diagramming tools can be very programmes. effective communication tools. • reuse (of work products and solutions/ parts). • Mature v. innovative technologies. • Business solution and technology roadmaps and long-term plans. Being clear on how these topics are captured and shared is key to informed debate, decision making and solution/ technology planning – things which all enterprise architects should be passionate about. the people We probably all know that at the end of day, how well a job is done is down to how good the people are. now, I don’t expect to have a supply of really good experienced architects always on hand to choose from. But having clearly defined roles and responsibilities helps everyone Secondly – think of the logical topology develop and do their job that much better. and functions – should the system be This is particularly true in terms of the centralised/federated/distributed, what major areas of ‘requirements analysis’ and major components are required in terms ‘solution design’. Consider now on the of business logic/data stores/network- teams you are part off or involved with – is ing/input/output/working processes/etc, it clear who is the requirements authority? what throughput and capacity do these (i.e. someone you can rely on in terms components require. Even at this more of knowing the client’s business and who elaborated design detail, fairly standard can speak authoritatively on their behalf diagramming packages can capture all on what they really need). Likewise, is you need to then frame your thinking there an individual or group recognised about the physical mapping onto specific as the design authority (i.e. someone you technologies and products. can rely on who knows the strategic IS/IT GEAO news January/February 006
  5. 5. Membership Continued from page direction, the applicable standards and news in brief can understand and influence the overall solution such that it meets requirements). I have certainly encountered teams where, gEao Website in a number of cases, I think the answer is either ‘no’ or ‘unclear’ and I am not sure The launch of our new website, which which is worse! So think about: was announced in our last newsletter, has been delayed. The new website will now • The team structure and expertise to be launched at the end of February. cover all necessary EA domains. • Having clear roles and responsibilities Certification written down - overlaps can be worse In 2005 we have seen an increased inter- than gaps. est in certification from members and the • Define working principles and delivera- public. We received many enquiries about bles. our certification programme and about • Balancing project/delivery exposure the process people need to go through and general architecture awareness. to become a “GEAO Certified Enterprise For me, getting roles defined and ac- Architect”. cepted by all is key. And bear in mind that We will continue to work on our certifi- for these roles to maintain their position cation programme in 2006. Associate of authority, there is the need to continu- members who want to become a full ally balance project exposure and general member will need to meet the criteria for architectural/solution awareness to ensure certification. a wide experience and understanding of business issues, available design options More around our certification will be pub- and solution delivery – that’s how people lished on our new website and in the next build their credibility and ensure their newsletter. authority can be effective in influencing newsletter outcomes in the right way. The typography and layout of our newslet- ter has been changed to reflect our new the bottom line house style. All our communication mate- rial has been aligned with this new house So an effective architecture team style. We would like to hear what you think exhibits strong leadership, defined of our newsletter. If you have any feed- team structure and roles, effective back, comments, letters to the editor, or and consistent documentation, other material that you think is suitable for informed decision making, clear publication in our newsletter then please don’t hesitate and send it to publications@ design models and focused com- munication. The key is balancing structured and defined working advertising practices with enough documenta- We have also opened our newsletter tion to provide the ‘statements of for advertising. Advertisements can be record’ – we all at some point need submitted for a full page, half page and a to go ‘back to basics’ and say why quarter page. If you are interested in pub- lishing then please contact publications@ things were done the way they were! GEAO news January/February 006
  6. 6. Article series - Part 2 Enterprise Architecture as a Corporate Competency by mark sternberger In our first installment of this series (Enterprise Architecture as a Cor- porate Competency - Part 1), we presented an anecdotal “get well” program to help folks get over the brain cramp caused by the musings entitled “IT Doesn’t Matter” provided by a Harvard Business review editor-at-large which effectively accomplishes nothing other than cre- ate divisiveness in enterprises accomplishing the Business-Technology Convergence Imperative. In Part 1, we promised with this second install- ment, some discussion of best practice for improving IT PArTS, which we will do later. This is the second in a series planned But first, I’m sitting here wondering what technology can bring through “agility.” All to share Enterprise Architecture trends, would make a good lead in. Well, David too often, it seems to me information tech- enabling mechanisms, and experiences Linthicum and I were recently chatting nology is labeled as a “cost center”, driven about if the key value of SOA is more by a desire to keep cost center costs to from actual client engagements. about “reuse” or “agility” (http://www.ebizq. a minimum. Obviously such a view does net/blogs/linthicum/archives/2005/12/is_ not promote the concept of architecture soa_more_abo.php). as a corporate competency, if supports an architecture practice at all. Especially for It occurred to me this would be a perfect publicly held companies, the entire view of lead in to the second installment of this technology must evolve towards a model multi part series discussing “Enterprise for revenue uplift, adding to the “top line”. Architecture as a Corporate Competency.” David was positioning that “reuse seems What MarkITS clients share as their busi- to be a key component, with the most of ness priority is to realize a strategically those implementing a SOA pointing reuse planned and tactically delivered technol- out as a key driver…this trend will con- ogy stack which is able to efficiently adapt tinue”. David closes with, “agility should to rapidly changing market demands that always be in the in the back of your mind allow the business agility in taking advan- when building out to a SOA, more so tage of new market opportunities, such as than reuse”. He and I agree, but I prefer merging or B2B partnering, without having advise our clients that “agility” is in fact, change impacts reverberate throughout not in the back of our minds, but rather, the legacy technology solutions. If I’ve not at the forefront and in reality, is what sold you on “agility” being the core of your drives the business to sponsor and fund architecture competency elevator pitch, SOA initiatives specifically, and enterprise let me vent on the “reuse” term. Don’t mis- architecture competencies in general. The understand, I’m as big a “reuse” bigot as senior executives that MarkITS partners anyone, just ask folks whom I worked with with more often express that they are me or MarkITS! unfortunately, our industry less concerned about the “bottom line” overloaded the term “reuse” during the and more attentive of the “top line.” In 90’s, creating a buzz that over promised other words, the guy paying to keep the and under delivered, primarily as a result lights on, is not so concerned about “how” of the difficult paradigm shift for those not (reuse vs. copy vs. rewrite vs. reinvent) re- experienced with OOAD techniques, silient architectures are derived, but rather and, too little attention paid to architecture what is the revenue uplift value proposition tenets. OO without architecture is almost GEAO news January/February 006 6
  7. 7. Article series - Part 2 as much a death march as OO with a ice-breaker to get the discussions going as waterfall methodology/process rather than a strategic goal, agility will not be realized an iterative process. As a result, when I without great PArTS (Performance, Avail- see “competitors” touting “reuse” as the ability, Adaptability, reliability, reusability, cornerstone of their digital strategy to busi- Testability, Scalability, and Supportability). ness sponsors, I’m joyful, because as a Enterprises can utilize PArTS as a set value proposition today, it typically lands of objectives-driven criteria that can help on the table with a resounding thud, fol- empower corporations to retain enter- lowed by deathly silence. Senior business prise architecture as a core competency sponsors have been conditioned to turnoff for competitive advantage. We call these as soon as they hear the term “reuse”. “objective-driven” criteria as they are Our experience in advising executives in useful for helping stakeholders define Enterprise Architecture and IT Govern- architecture tenets across all architecture views (Part 3 will discuss architecture views in context of the DEADOnS (De- velopment, Execution, Application, Data, Operational-business, network, and Security) architecture views. In addition PArTS serves as guideposts for helping identify and assess change impacts with metrics based inputs. unfortunately, all too often, subjective-driven superstition, black magic, and Kentucky windage are utilized for change management decisions and merger decisions. Below is what we mean when we talk about helping companies build and navigate roadmaps resulting in IT solutions exhibiting improved PArTS. performance: application architectures and designs if poorly conceived can exponentially bottleneck application performance as ance stewardship of their strategic and business rule complexity deepens and tactical initiatives has shown that the OO broadens. Design mechanisms regarding buzz of the 90’s unfortunately left C- dynamic load balancing, levels of indirec- Level colleagues a rather underwhelming tion, memory management, consistent impression about class/object/component usage of foundation methods, how execu- “reuse” which for the most part never tive service requests are wrapped, calling materialized for them. Conversely, “agil- trees and class hierarchies, inter and intra ity” is greeted with much greater interest process communications and external as it is a much easier recognized value interface design and implementation is- proposition for senior executives who want sues are examples of performance metrics technology to respond to their immediate which if not properly applied can adversely business opportunities offered by inorgan- effect the system throughput. Visual ic growth or B2B partnerships. Especially modeling is an important mechanism for given a resilient enterprise architecture is identifying otherwise unrealized optimiza- only realized as a direct result of design- tions. How object-relational mappings are ing for “agility.” We find that “agility” is the implemented is important for streamlining key value proposition that resonates with performance if metadata relationships are funding sponsors AnD technology teams. not efficient. Agility is the most sellable, bridging goal between business and technology which database architecture and design con- both organizations can quickly agree upon sists of metadata management, numbers as common ground and is a great starting of tables, dimensional views, columns, point to lead organizations to succeed in referential integrity, the degree of normali- Business-Technology Convergence. Let’s zation and the effective application of the remember however, that while key as an 3rd party DBMS services used to imple- ment the designs and maintain the content GEAO news January/February 006
  8. 8. Article series - Part 2 within the schemas. The % of “business are the acceptable levels of availability entity” indicative data vs. supporting data as defined by the business? When can for error handling, defects and ancillary the system be not available for archival data support embedded within the appli- purposes, if ever? This availability may cation DB is an important realization. DB decrease at faster than linear rate as the visual modeling is an important tool for volume of users for an alternative busi- identifying otherwise unrealized optimiza- ness line or as complexity of the business tions. increases over time. adaptability: reusability: Modularity, internal subsystem and entity Component vs. object approach and cohesion, low levels of coupling are gen- understanding the design mechanism eral goals which promote lower Total Cost differences and establishing consistency of Ownership, decrease time to market across the design team is important. for future releases by maximizing reuse, Either approach is effective when properly generally extend the life expectancy of adhered to. The goals “high degree of co- applications. Interpretive languages are hesion” internal to entities and “low degree great for prototyping and experimentation of coupling” between entities are important proof of concept, but for production sys- design principles. This maximizes oppor- tems generally do not provide the robust tunities for future business lines, makes qualities necessary. Compiled applications maintenance costs lower, and decreases on the other hand require a conscious the time to market for new applications or new releases and fixes. reliability: Does the system provide consistent repeatable results under all the various operating modes, stresses and durations? 1. What is the mean time between con- tent errors? 2. number of outstanding content or functional defects open; 3. Average time to resolve a content or functional defect. testability: Traceability is a key driver in assuring a system is testable. A clear and succinct response these types questions can be quite telling and also indicates how good effort to design adaptability by applying the other PArTS areas will be for an ap- effective “chunking” skills to increase plication. Test documentation availability modularity, plug ‘n play effectiveness via including use Cases, Test Cases, Test API’s, wrappers, and minimal interfaces or Plans and Test Procedures and a trace- otherwise “hidden dependencies” which ability between these artifacts yield great can inhibit non-intrusive modification insights into the overall evaluation. upgrades. supportability: availability: application – Look for indicators of high Does the application and DB design support needs due to low levels of inherit- provide high availability to users for all ance, poor component packaging or lack levels of concurrent transaction volume of packaging altogether, complex make- targeted? Where are the degradation files and build procedures, unreadable thresholds for high availability and what on non-self documenting source code, GEAO news January/February 006
  9. 9. Article series - Part 2 infrastructure functionality and rules which able, but somewhat burdensome if there are not separate from business rules, are high degrees of redundancy of base many redundant copies of foundation rules rules in multiple modules. Effective uses which can potentially exist throughout the of “infrastructure” vs. “business” rules application. Be aware of strong technical encapsulated within appropriate modules leads which can seemingly speak to and are utilized to limit potential proliferation of mask these problems on the surface but redundant base rules spreading through- yet has a team which otherwise has little out an application causing increased knowledge transfer across the team which future maintenance costs. impedes an efficient support model. In this scenario, as the application matures with changing personnel, this is a risk is exacerbated. Visual modeling would vastly improve the supportability through effec- tive knowledge transfer. database – Is there a high degree of dependencies and referential integrity maintenance that is required which may cause inefficiencies. Look for recurring tables and content. Look to see if effec- Mr. Sternberger is the Founder and tive use of lookup tables has been applied CEO of Mark Associates Integrated which is a technique often used to make Technology Solutions, a premier digital up for design shortfall in an attempt to synchronization services firm. In addi- increase operational performance in table tion to managing MarkITS, he functions lookups at the great expense of supporta- bility and reliability. Visual modeling would as Director of Enterprise Architecture vastly improve the supportability through Services and Chief Architect driving effective knowledge transfer. business-technology convergence for the Merger and Integration Office of MarkITS’s primary financial services scalability: client. He is responsible for application, volume – From a context of the applica- data, and technical architecture views, tion threading mechanisms and database modeling, and oversight of tactical update mechanisms and evaluation of teams’ adoption and implementation metrics such as number of transactions of the SOA framework. In addition, he per time increment, number of concurrent oversees outsource vendors, tools, and users that can be handled, and under- standing where the degradation occurs provides budget and personnel admin- along the graph and if the degradation istration of the Enterprise Architecture curve is linear or exponential are important Services organization. He brings over characteristics to understand. Will apply- 20 years of software systems engi- ing more hardware into the environment neering for embedded and distributed effect scalability or is there a software platforms for start-ups, Fortune 500, threshold which when reached will no and Government clients developing longer result in increasing transactions or end products or solutions for diversi- users. Most importantly, does the applica- tion and DB design render themselves to fied Financial Services, Networking, be tweaked and improved upon, in other Comanche Helicopter Avionics, Sonar words can they be scaled and does do Simulation/Telemetry Control, Trident they respond to adjustments? To what de- Submarine C3I, and Physical Sciences gree can foundation components be easily Computer Simulation to assure clients modified to provide different functionality improved IT PARTS (Performance, by the application, i.e. change once, effect Availability, Adaptability, Reuse, Relia- many vs. change many to effect once. bility, Testability, Traceability, Scalability Extensibility – Detail design extensibil- and Supportability). ity while a bit cumbersome with some script based loosely typed and COM like Email: partitioning can be adequate and manage- Web site: GEAO news January/February 006
  10. 10. Article From Service Oriented Architecture to Service Oriented Enterprise by vijay seetharaman Service Oriented Architecture (SOA) has been on the tabloid for quite some time now and as with any new concept in the information age has been subjected to the “well-known” hype-cycle. Gartner currently puts SOA in the trough of disillusionment, though it appears that the slope of enlightenment is not far away. With increasing vendor support, emer- gence of maturing standards and clarity around its definition, lifecycle and benefits, the SOA promise appears real. Vijay Seetharaman is a systems Enterprises are far from realising the full benefits of SOA. However, architect with in the EDS Portfolio planning for SOA promises significant business transformations in the Development organisation. In his long term. This article discusses the emerging common themes around role, Vijay is responsible for providing SOA. The discussion below is based on best practices and experiences architectural and technology consul- of SOA practitioners who shared their knowledge at the Open Group’s IT tancy services for realising the EDS Architect Practitioners Conference in Barcelona. portfolio of service offerings to clients in a number of industry segments What is soa? ness processes exposed by internal that includes government, telecom- business units, suppliers and partners It is interesting to see how the term and their integration; “Publish” includes munications, ERP/Supply chain and SOA figures in every organisations IS/IT concepts such as business registries and Financials. He is also a founding roadmaps. Every conference has a SOA directories; “Discover” includes search member and the current Director of stream which runs packed sessions. mechanisms that span these registries; Technology for the Global Enterprise Google hit count, also called the Google “Invoke” includes business protocols for Architecture Organisation. Vijay is Quotient (GC) puts SOA at 10 million (only interacting with these services and “net- an Open Group’s Master certified IT less than Britney Spears at 12 million!). So work” includes partners, supply chain and Architect and has a Masters degree in what is SOA and why is it important? business units. Computer Science (IIT, Chennai) and a There are so many definitions of SOA but Similar definitions for information, technol- Bachelor’s degree in Computer Science the common pattern emerging from these ogy and applications are also possible. and Engineering (NIT, Trichy). definitions seem to include the following Very often SOA is equated to the Service terms: Architectural approach, loosely Oriented Application Architecture with Web coupled, collaborating services, publish, Services as the key technology enabler for discover and invoke. Stringing these building such applications. In this article, words together results in one possible we shall see how SOA principles apply to definition: “An architectural approach to a functioning enterprise. building a set of loosely coupled collabo- rating services that can be published, discovered and invoked over a network”. service oriented The definition covers a lot of ground based Enterprise on the scope of each of the terms in it. The concept of a Service Oriented Enter- For example, “An architectural approach” prise is gaining importance in the context could include “Business Architecture” of SOA. We shall see the characteristics which then constraints the semantics of of a Service Oriented Enterprise before at- the other terms in the definition. “Loosely- tempting to define what a Service Oriented coupled” now includes cross-business, Enterprise is. “Collaborating services” includes busi- GEAO news January/February 006 10
  11. 11. Article A Service Oriented Enterprise is: SOA, extended to the enterprise covers all aspects of the functioning enterprise 1. Externally adaptive - being able including, business, information, applica- to easily forge new relationships with tions and technology infrastructure. suppliers, partners and other busi- nesses. Figure 1 illustrates the concept and shows . internally agile - has streamlined the key enablers of a Service Oriented business processes and systems that Enterprise at each enterprise architectural are able to quickly respond to changes domain. The transformation to a Service in the business Oriented Enterprise requires a Service Oriented Architectural approach that tran- . collaborative and responsive to scends the various architectural domains customers and partners - being in the enterprise’s architecture. Let us able to aggregate and share real- briefly discuss one such Service Oriented time information with customers and Architectural approach. partners and provide online-services that allow integration of people and processes in a seamless fashion. the soa approach Given these characteristics, a Service Figure 2 shows the SOA approach that Oriented Enterprise can be defined as comprises of: an organisation with a service oriented enterprise architecture. It is an organisa- Services Identification, Modelling tion whose: and design 1. Mission level objectives are imprinted Services Modelling and Design is a key in a set of business services. step in the enterprise transformation proc- 2. Business Services are translated to ess to a Service Oriented Enterprise. This key IS/IT services that: process identifies, models and designs • Fulfil the information needs of the services based on business objectives. enterprise. Service identification is a fairly sophis- ticated process. For a Service Oriented • realise the business functionality Enterprise, services provide the capabil- (rules and logic). ity that enable the business to achieve • Support the operational characteris- its mission level objectives. Services tics of the enterprise (performance, should be closely aligned to the business availability etc). objectives. The Services Identification, 3. Business Services drive IS/IT services Modelling and Design exercise lays the into a state of dynamic equilibrium. foundation for SOA where existing IT sys- That is, IT systems change quickly to tems and new systems could be mapped meet business changes and business or aligned to provide the key capabilities embraces IT innovations to gain a of the enterprise when executing its long competitive edge. term vision thus enabling business IT Figure 1 alignment. Business Process Management, Industry Frameworks Service Oriented Business Business Intelligence, Warehouses, Master Data Service Oriented Information Management Service Oriented Applications Composite Applications and Service Oriented Infrastructure Portals Web Services, ESB, Virtualisation, Utility computing, Grid Services GEAO news January/February 006 11
  12. 12. Article This section provides an overview of a 1. How reusable the business service very simple service modelling technique. is? Can the service be reused in more then one business context as part of At a high-level, the technique works as different business processes? follows: From the mission level business objectives of the organisation (identified 2. Does the business service yield an as part of qualifying the organisation’s outcome of value that can be directly vision and business strategy), a set of tied back to the original business business processes are identified. A busi- objectives? While the business proc- ness process, typically a workflow from esses relate back to the objectives, the organisation’s point of view, is a set of there could be activities in the busi- activities performed by a set of workers in ness process that do not directly trace a given sequence that yields a measur- back to the key objectives. However, able outcome to the business. Examples these are required to support the include, Service Order Management, business process. There may be Figure 2 little benefit in creating independent services from such activities. These activities should be part of a business SOA Governance service that does trace back to the objectives. 3. Based on guidelines, principles, Services Build and Exposition policies and constraints set by the business. Services Once the business services have been Services Identification Discovery and identified, these can then be directly Modelling and Composition translated into IS/IT services at the various Design levels of the IT architectures (information, application, technology infrastructure. The Service Services criteria use for identification includes: Operationalisation Deployment and and Management Provisioning 1. Business objectives 2. Clustering of business services based on the information model they access. 3. Mapping of business services to exist- ing IT systems and functionality Expense Claims Management etc. If the . IT standards and policies organisation already has a set of business processes, then these processes are tied services build and Exposition back to the business objectives. If a busi- In this step, the identified IS/IT serv- ness process cannot be mapped back to a ices are then realised at the different IT mission level objective, then the existence architectural domains such as informa- of the process is questioned. However, tion, application and infrastructure. These note that there could be processes that do services are then exposed using service not directly map back to business objec- registries. tives but are required to support other core business processes. Such processes are Once services are created they should be grouped alongside the core processes that made visible to the rest of the enterprise. they enable. This is done using service registries. Service contracts are exposed through Once a minimal set of such processes has the registries and consumers can build been identified, each one of the process in composite services. the set is then broken into a set of busi- ness activities. A business activity is a task There is increasing vendor support for or a unit of work, performed by a worker building application services and exposing (or a role) that achieves a measurable them through registries. In this context, outcome. Examples include, creating a the Enterprise Services Bus concept has service request, approving a claim etc. gained relevance, as the infrastructure for building, exposing, discovering, invoking The business activities are then logically and managing application services. grouped into business services based on the following criteria: GEAO news January/February 006 1
  13. 13. Article There are also standards for building deployment and provisioning of application should provide tools that monitors service application services and exposing their services. execution and provide real-time view of contracts. The most popular standard for the service activity. Provisioning of services to clients needs to realising an application service is “Web support the following functionality: governance Services” (SOAP, WSDL). 1. A registry of published services with As seen from the SOA approach diagram, services discovery and their licensing details and usage rates governance is integral to the SOA lifecycle composition – Details about the service and rates and encompasses all the steps involved In this step, services are discovered from associated with usage could be de- in the creation of a SOA. In addition to the registry and are composed to create scribed as meta-data associated with regulating the adoption of SOA through composite services. The service discovery the service and stored in the repository policies and measures, SOA governance and composition concept is more mature 2. Service licensing and tracking of also include aspects of corporate govern- in the application domain. license usage – Once the consumer ance. Frameworks such as CobIT, could dynamically discovers a service from be employed to ensure business / IT align- A standards based specification that the registry, it then needs to agree to ment, regulatory/government compliance closely ties with Web Services is the the licensing terms associated with the requirements around security, auditing and universal Description, Discovery and usage of the service. This subscription reporting practices. Integration (UDDI). UDDI is a specification process needs to be managed and the that describes services in a platform- usage tracked. acknowledgments independent manner, and defines how businesses can dynamically discover and 3. realtime metering, usage rating and 1. “How an Integrated Architecture Framework integrate over the Internet. uDDI provides billing – The usage is tracked real-time can help organisations become a Serv- a framework for the description of basic which is later rated and billed ice Oriented Enterprise? A case study”, business and service information, and . License enforcement – Ensuring that Philippe Andre, IT Architecture Practitioners architects an extensible mechanism to the consumer uses the service in Conference, Barcelona 2006 provide detailed service access informa- compliance with the original licensing 2. “SOA governance: a key ingredient of the tion using standard description languages. terms associated with the usage of the Adaptive Enterprise”, Ben Brauer, Sean service. Kline, Feb 2005 The Enterprise Services Bus is an infra- structure for services that provides these services operationalisation and 3. “SOE What?”, Stuart Crawford, IT Architec- capabilities for services that reside in it. management ture Practitioners Conference, Barcelona 2006 services deployment and The operational aspects of the services . “Service Oriented Architectures: The Busi- provisioning are defined. Applications, identity and ness of Services”, Peter D. Bouchard, IT compliance aspects are managed and key Here, services are deployed and provi- business metrics/activities are monitored. Architecture Practitioners Conference, sioned for consumption by specific clients The infrastructure that hosts the services Barcelona 2006 (enabling metering and billing). Deploy- ment of a service could be a complex task. This has to deal with different environ- ments for deployment, the migration of conclusion services from one to the other, configura- In conclusion, a service-oriented architecture is an architectural ap- tion management of production services proach that addresses the business and IT challenges by introducing etc. While this concept is valid for services adaptability and agility into the operational aspects of the functioning across all architectural domains, it is more mature and well understood in the enterprise. An enterprise built on the SOA principles then transforms application domain. The ESB and ven- to a Service Oriented Enterprise with a greater alignment of IT with dor supplied tools should assist with the business goals. GEAO news January/February 006 1