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