This presentation will cover first exam of SOA , by introducing terms related to Service oriented Computing umbrella to start your knowledge base about Service Orientation world.
Enterprise Architecture linking to Chess and Lego games , and main capabilities of EA framework , concentrating on Togaf as common Enterprise architecture framework.
Enterprise Architecture linking to Chess and Lego games , and main capabilities of EA framework , concentrating on Togaf as common Enterprise architecture framework.
This whitepaper considers the alignment of ITSM within a TOGAF aligned enterprise.
A key driver for having such an alignment is to remove the business execution silos that come to exist in an enterprise when implementing projects that fall under either ITIL 3 or TOGAF 9. At a high level, we propose to remove such silos by creating a mapping between the two frameworks as well as between ITSM and TOGAF 9. This should create a standard set of artifacts or standard interfaces between those artifacts so that an enterprise may have a common platform for both service management and enterprise architectures. Such commonality is best implemented at the initial requirements establishment phase of an initiative and so the necessary information sharing and processes should be in place at the outset.
Our recommendation is for this to happen within the wider TOGAF 9 context where ITIL 3 can be considered as an integral extension of enterprise architecture. This is achievable because there is a lot of synergy between ITSM’s ITIL 3 and the TOGAF 9 framework, especially since TOGAF 9 has shifted to a more service-orientated approach to Enterprise Architecture.
The latest version of the TOGAF standard has special emphasis on Business Architecture, Digital Trends, and Business Transformation beyond IT. Stuart Macgregor takes us through some of these changes to the TOGAF® 9.2 standard and discuss how they will benefit us.
Practical Enterprise Architecture in Medium-size Corporation using TOGAFMichael Sukachev
Overview on the Practical Enterprise Architecture approach using TOGAF ADM for architectures development, Zachman Framework as artifacts repository and Sparx EA as a modelling tool.
Very useful set of TOGAF-related diagrams from the Orbus Software.
TOGAF®9.1 is an Architecture Framework which has been developed by the Open Group to provide the methods and tools
for assisting in the acceptance, production, use and maintenance of an Enterprise Architecture.
What is the Value of Mature Enterprise Architecture TOGAFxavblai
Judith Jones received the Open Group award for Outstanding Contributions to the development of TOGAF 9 at 19th Open Group Enterprise Architecture Practitioners Conference Chicago - July 21-23, 2008. Former CEO of Architecting the Enterprise which has been a member of The Open Group for 6 years, she is personnally involved since 1997. As an active member of The Open Group and she is a major contributor and an editor of TOGAF 7, 8 and 9 as well as leading TOGAF projects for localisation, case studies, ADML, synergy and collaboration projects.
http://www.opengroup.org/member/member-spotlight-jones.htm
When a company invests in ITIL, very often Architecture is not much involved: this is a mistake because there is much overlap, and Architecture can end up side-lined by the ITIL juggernaut. But there are a lot of benefits Architecture can bring to an ITIL-oriented organization.
This slide deck goes a step or two further than the white-papers out there I've found to date in providing some concrete guidance on how to actually integrate Architecture activities into ITIL. The deck uses TOGAF as the reference framework, but the concepts can be applied to any modern Architecture practice, since the discussion focuses on the types of deliverables and activities, which analogously exist in most frameworks.
Togaf is a high level and holistic approach to design, which is typically modeled at four levels: business, application, data, and
technology. It tries to give a well-tested overall starting model to information architects, which can then be built upon. It relies heavily
on modularization, standardization, and already existing, proven technologies and products.
For More Information please follow the below link:
http://www.xoomtrainings.com/course/togaf
For Togaf 9.1 Online Training Demo Please Find the below link:
https://www.youtube.com/watch?v=TF-h6yUc9eo
For General Queries Email us at sales@xoomtrainings.com or +1-610-686-8077
TOGAF - a teaser for our traning courseLars Lundgren
Level 1
Provide validation that the Candidate has gained knowledge of the terminology, structure, and basic concepts of TOGAF 9.1, and understands the core principles of Enterprise Architecture and TOGAF.
Level 2
Provide validation that in addition to the knowledge and comprehension of Level 1, the Candidate is able to analyze and apply this knowledge. The learning objectives at this level focus on application and analysis, in addition to knowledge and comprehension.
This is a very short introduction to The Open Group Architecture Framework -- a framework for enterprise architecture. It is meant to provide an executive summary of what TOGAF is and also provide a few reasons why you should use it.
This whitepaper considers the alignment of ITSM within a TOGAF aligned enterprise.
A key driver for having such an alignment is to remove the business execution silos that come to exist in an enterprise when implementing projects that fall under either ITIL 3 or TOGAF 9. At a high level, we propose to remove such silos by creating a mapping between the two frameworks as well as between ITSM and TOGAF 9. This should create a standard set of artifacts or standard interfaces between those artifacts so that an enterprise may have a common platform for both service management and enterprise architectures. Such commonality is best implemented at the initial requirements establishment phase of an initiative and so the necessary information sharing and processes should be in place at the outset.
Our recommendation is for this to happen within the wider TOGAF 9 context where ITIL 3 can be considered as an integral extension of enterprise architecture. This is achievable because there is a lot of synergy between ITSM’s ITIL 3 and the TOGAF 9 framework, especially since TOGAF 9 has shifted to a more service-orientated approach to Enterprise Architecture.
The latest version of the TOGAF standard has special emphasis on Business Architecture, Digital Trends, and Business Transformation beyond IT. Stuart Macgregor takes us through some of these changes to the TOGAF® 9.2 standard and discuss how they will benefit us.
Practical Enterprise Architecture in Medium-size Corporation using TOGAFMichael Sukachev
Overview on the Practical Enterprise Architecture approach using TOGAF ADM for architectures development, Zachman Framework as artifacts repository and Sparx EA as a modelling tool.
Very useful set of TOGAF-related diagrams from the Orbus Software.
TOGAF®9.1 is an Architecture Framework which has been developed by the Open Group to provide the methods and tools
for assisting in the acceptance, production, use and maintenance of an Enterprise Architecture.
What is the Value of Mature Enterprise Architecture TOGAFxavblai
Judith Jones received the Open Group award for Outstanding Contributions to the development of TOGAF 9 at 19th Open Group Enterprise Architecture Practitioners Conference Chicago - July 21-23, 2008. Former CEO of Architecting the Enterprise which has been a member of The Open Group for 6 years, she is personnally involved since 1997. As an active member of The Open Group and she is a major contributor and an editor of TOGAF 7, 8 and 9 as well as leading TOGAF projects for localisation, case studies, ADML, synergy and collaboration projects.
http://www.opengroup.org/member/member-spotlight-jones.htm
When a company invests in ITIL, very often Architecture is not much involved: this is a mistake because there is much overlap, and Architecture can end up side-lined by the ITIL juggernaut. But there are a lot of benefits Architecture can bring to an ITIL-oriented organization.
This slide deck goes a step or two further than the white-papers out there I've found to date in providing some concrete guidance on how to actually integrate Architecture activities into ITIL. The deck uses TOGAF as the reference framework, but the concepts can be applied to any modern Architecture practice, since the discussion focuses on the types of deliverables and activities, which analogously exist in most frameworks.
Togaf is a high level and holistic approach to design, which is typically modeled at four levels: business, application, data, and
technology. It tries to give a well-tested overall starting model to information architects, which can then be built upon. It relies heavily
on modularization, standardization, and already existing, proven technologies and products.
For More Information please follow the below link:
http://www.xoomtrainings.com/course/togaf
For Togaf 9.1 Online Training Demo Please Find the below link:
https://www.youtube.com/watch?v=TF-h6yUc9eo
For General Queries Email us at sales@xoomtrainings.com or +1-610-686-8077
TOGAF - a teaser for our traning courseLars Lundgren
Level 1
Provide validation that the Candidate has gained knowledge of the terminology, structure, and basic concepts of TOGAF 9.1, and understands the core principles of Enterprise Architecture and TOGAF.
Level 2
Provide validation that in addition to the knowledge and comprehension of Level 1, the Candidate is able to analyze and apply this knowledge. The learning objectives at this level focus on application and analysis, in addition to knowledge and comprehension.
This is a very short introduction to The Open Group Architecture Framework -- a framework for enterprise architecture. It is meant to provide an executive summary of what TOGAF is and also provide a few reasons why you should use it.
Service Oriented Architecture.
SOA is a style of architecting applications in such a way that they are composed of discrete software agents that have simple, well defined interfaces and are orchestrated through a loose coupling to perform a required function.
Business and IT leaders are understandably reluctant to retire considerable, legacy investment in technology, people, and processes due to security, risk, and regulatory compliance obligations. This creates a hybrid IT deployment model: an on-premise landscape of existing or legacy systems and off-premise cloud deployment of suitable IT capability.
The ODCA believes that integration of cloud deployments with enterprise landscapes should consider people, process, technology, and operating models. Doing so encourages faster cloud adoption, leverages existing enterprise investments in IT landscape and helps govern safe cloud adoption through effective risk and compliance management.
Watch webinar on-demand at https://www.brighttalk.com/channel/9831
Download “Cloud Coexistence with Extant Enterprise Systems,” a whitepaper published by ODCA and top member companies.
This document is an overview of a Private Cloud Reference Model. For the purposes of this document, a Reference Model is defined as the problem definition, requirements, and scope for a specific domain including the identification of all layers (or subdomains) and any interactions or dependencies between the components.
this series of Service-oriented computing will explain in details session after another , the core knowledge about service orientation , so be ready ..
Architecture thinking series W001 - present architecture discipline including integrated domains ( business strategy , business architecture and enterprise architecture)
and basic concepts behind Architecture Thinking
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
7. SOA & EA
▷ Overall construction of the enterprise
▷ Includes much more than IT than IT
▷ Covers business operations, finance,
people, buildings and technology
▷ Particular construction technique
to build enterprise IT
▷ Part of the enterprise architecture
▷ Major impact on the overall construction
14. Session Agenda
1. Fundamental Service-Oriented Computing Terms
2. Strategic Goals of Service-Oriented Computing
3. SOA and service Orientation
4. Planning and Governing SOA
5. SOA Project Delivery Approaches and Planning
6. Primitive service modeling process
16. Service Oriented Computing
New generation distributed computing platform include:
▷ Its own design paradigm (principles)
▷ Design pattern catalogs
▷ Pattern languages
▷ A distinct architectural model,
▷ Related concepts, technologies, and frameworks.
Big umbrella in the
world of services
Builds upon past distributed computing platforms and adds :
▷ New design layers
▷ Governance considerations
▷ Set of implementation technologies.
20. 1. Service Orientation Principles
Standardized
Service
Contract
Service
Reusability
Service
Composability
Service
Autonomy
Service
Loose
Coupling
Service
Statelessness
Service
Abstraction
Service
Discoverability
21. Service Orientation Principles
Service Reusability
Service contain agnostic logic that can be position as reusable enterprise resource.
Standardized Service Contract
Service in same inventory are in compliance of same design service contract standards.
Service Composition
Services are effective composition participants.
Service Discoverability
Service meta data available for discoverability and interpreted.
Service Loose Coupling
Contract decoupled from surrounding environment.
Service Autonomy
Services exercise a high level of control over underlying runtime execution environment.
Service Statelessness
Services minimize resource consumption , reduce state information.
Service Abstraction
Contract contains only essential information , that is published to consumers.
22. 2. Service Orientation Solution logic
▷ The application of Service Orientation principles to the design of solution logic
results in service-oriented solution logic
▷ Service-oriented solution logic is implemented as services and service compositions
Principles
Goals
Service
Composition
Service
Solution
Logic
23. 3. Service Orientated Architecture
▷ Architectural model aims to enhance efficiency, agility, and productivity of an enterprise.
▷ Position services as primary means through which solution logic is represented in support
of realization of strategic goals associated with service-oriented computing.
▷ Service-oriented computing revolves around service-orientation design paradigm
and its relationship with service-oriented architecture.
▷ SOA Implementation can consist of
▷ Technologies
▷ Products
▷ APIs
▷ Supporting infrastructure extensions
▷ Various other parts
24. 4. Service
▷ Independent software programs with distinct design characteristics
Service with
functional context
Solution
Logic
Is a Unit of
Goals
help attain of
25. 4. Service - Capability
▷ A service is a container for a collection of related functions.
These functions are called service capabilities
▷ Capabilities exposed via a service contract establish a basic API by which the service
can be invoked.
▷ Capabilities Useful during service modeling stages when physical design
of a service has not yet been determined.
Once it is known whether a service exists as a Web service
or as a component, the terms "service method" or “
service operation" can be used instead
26. 5. Service Composition
▷ An aggregate of services collectively composed to automate a particular task
or business process.
▷ To qualify as a composition, at least two participating services plus
one composition initiator need to be present.
▷ service naturally and repeatedly composed is fundamental
to attaining several of key strategic goals of
service-oriented computing.
▷ Service-orientation design paradigm revolves around
preparing services for effective participation
in numerous complex compositions.
27. 6. Service Inventory
▷ collection of complementary services within a boundary that represents an
enterprise or a meaningful segment of an enterprise
▷ Service inventories are typically created through top-down delivery processes that
result in the definition of service inventory blueprints.
29. 6. Service Inventory (Blueprint)
Service Inventory blueprints is a Collection of Candidate services in analysis phase
that need to analyzed and refined as necessary before committing to the actual
creation of a physical service inventory
30. 6. Service Inventory (Service Models)
Classification used to indicate that a service belongs to one of several predefined types
based on the nature of the logic it encapsulates
Entity Service
▷ Reusable service with an agnostic functional context
▷ associated with one or more related business entities
Utility Service
▷ Reusable service with an agnostic functional context
▷ Not retrieved from business encapsulates low-level technology-centric functions
▷ such as notification, logging, and security processing.
Task Service
▷ A service with a non-agnostic functional context
▷ Generally corresponds to single-purpose
▷ A task service will usually encapsulate the composition logic
34. Service Oriented Computing Goals
Increased Intrinsic Interoperability
Service designed to be naturally compatible, no effort need for integration
Integration VS
Interoperability
35. Service Oriented Computing Goals
Increased Federation
Services establish a uniform contract layer hides underlying difference
36. Service Oriented Computing Goals
Increased Vendor Diversification Options
A vendor-neutral architectural model organization to evolve the architecture
without limited to proprietary vendor platform characteristics
37. Service Oriented Computing Goals
Increased Business and Technology Domain Alignment
services are designed with a business-centric functional context alignment with the business,
even as the business changes
38. Service Oriented Computing Goals
Increased Return on Investment (ROI)
Services are delivered and viewed as IT assets expected to provide repeated value, that will
cover exceed cost of delivery and ownership
39. Service Oriented Computing Goals
Increased Organizational Agility
Rapid delivery , New and changing business requirements can be fulfilled rapidly
40. Service Oriented Computing Goals
Reduced IT Burden
providing more value with less cost and less overall burden reduced waste and
redundancy, reduced size and operational cost
41. Service Oriented Computing Goals
Increased Return on Investment (ROI)
Services are delivered and viewed as IT assets expected to provide repeated value, that will
cover exceed cost of delivery and ownership
Increased Organizational Agility
Rapid delivery , New and changing business requirements can be fulfilled rapidly
Increased Intrinsic Interoperability
Service designed to be naturally compatible, no effort need for integration
Increased Business and Technology Domain Alignment
services are designed with a business-centric functional context alignment with the business,
even as the business changes
Reduced IT Burden
providing more value with less cost and less overall burden reduced waste and
redundancy, reduced size and operational cost
Increased Federation
Services establish a uniform contract layer hides underlying difference
Increased Vendor Diversification Options
A vendor-neutral architectural model organization to evolve the architecture
without limited to proprietary vendor platform characteristics
42. SOA and Service Orientation
▷SOA Characteristics
▷ Four Common Types of SOA
43. SOA Characteristics
Always align between technology
architecture and business needs
Business driven Vendor Neutral
Leveraging multiple vendor
technology innovations
Composition centric
services capable of being pulled
into a variety of composition
Enterprise centric
Enterprise resource is simply
logic positioned as an IT asset
44. 1. SOA Characteristics – Business Driven
Traditional technology architecture
For solutions delivered to fulfill tactical (short-term) business requirements
Result :
▷ Technical environment, over time, falls out of
alignment with organization's business direction
and requirements
▷ Increasingly difficult to adapt to
changing business needs
45. 1. SOA Characteristics – Business Driven
Business driven technology architecture
Business vision, goals, and requirements are positioned as the basis for and
the primary influence of the architectural model.
Result :
▷ maximizes the potential alignment of
technology and business
▷ continual increase in the value and life span of
the architecture.
▷ constant sync with how the business evolves
over time.
46. 2. SOA Characteristics – Vendor Neutral
Vendor-centric technology architectures :
Bound to corresponding vendor platform Roadmaps
Result :
▷ Reduce opportunities to leverage technology
innovations provided by other vendor platforms
▷ Need to eventually replace the architecture
entirely with a new vendor implementation
47. 2. SOA Characteristics – Vendor Neutral
neutral vendor platforms
Result :
▷ freedom to diversify its implementation by
leveraging multiple vendor technology
innovations.
▷ Increases the longevity of the architecture
▷ Architecture evolve in response to changing
requirements
48. 3. SOA Characteristics – Enterprise Centric
Single-purpose services
Delivered to automate specific business processes
Result :
Can end up establishing silos within the enterprise.
49. 3. SOA Characteristics – Enterprise Centric
Enterprise centric services
Enterprise resource is simply logic positioned as an IT asset
Result :
Extension of the enterprise that does not belong solely to any one application or solution
50. 4. SOA Characteristics – Composition Centric
Service built as flexible resources
that plugged into different aggregate
structures
services must be capable of being pulled
into a variety of composition designs,
regardless of whether or not they are
initially required to participate in a
composition when they are first delivered
51. Four Common Types of SOA
▷ Service-oriented technology architecture can exist at different scopes or levels of implementation
▷ These implementation levels are referred to as SOA types.
1. Service Architecture : The architecture of a single service
2. Service Composition Architecture : the architecture of a set of services
assembled into a service composition
3. Service Inventory Architecture : the architecture that
supports a collection of related services that are
independently standardized and governed
4. Service-Oriented Enterprise Architecture:
The architecture of the enterprise itself, to whatever
extent it is service-oriented
52. Planning and Governing SOA
▷Four Pillars of Service Orientation
▷Levels of organizational maturity
53. Planning and Governance of SOA
▷ SOA adoption require a long-term commitment that can demand essential rethink of an
organization’s business and the culture, technology, and priorities of its IT enterprise
▷ The following models and practices assist an organization in assessing its readiness and
maturity, and formalizing the manner in which the resources and assets produced by an SOA
project are regulated and evolved
1. Four Pillars of Service Orientation
2. Level of Organizational Maturity
54. 1. Pillars of Service-Orientation
▷ Teamwork : Cross-project teams and cooperation are required.
▷ Education : Team members must communicate and cooperate based on common
knowledge and understanding.
▷ Discipline : Team members must apply their common knowledge consistently.
▷ Balanced Scope : The extent to which the required levels of
Teamwork, Education, and Discipline need to be realized is
represented by a meaningful yet manageable scope
Good understanding of how these pillars represent
foundational requirements for successful SOA adoption
enables an organization to properly scope its adoption effort
55. 2. Levels of organizational maturity
▷ Organization begins planning for the adoption of SOA
▷ Organization transition through one or more of the following common evolutionary
levels:
56. Levels of organizational maturity
Service Neutral Level
No meaningful extent of teamwork, education, or discipline has been established
or yet identified
57. Levels of organizational maturity
Service Aware
Four pillars have been established, relevant business requirements and goals are
defined, and overall necessary organizational foundation for the SOA initiative is in place.
58. Levels of organizational maturity
Service Capable
Ability to deliver and govern services and service compositions in response to
business automation requirements
59. Levels of organizational maturity
Business Aligned
Organization has successfully aligned services and service compositions with the
current state of the business.
service inventory have been delivered and are in operation (mature service inventory)
60. Levels of organizational maturity
Business Driven
service-encapsulated technology resources are not just aligned with the current
state of the business, but have proven to remain in alignment with how business
requirements continue to change
61. Levels of organizational maturity
Service Ineffectual
IT enterprise delivers services as silo-based or bottom-up automation solutions
under the pretense that it is adopting SOA.
(most likely single-purpose software programs labeled as services)
62. Levels of organizational maturity
Service Aggressive
Generation of services that the business doesn't want or need , business may
not even be aware of their existence.
Due to lack of teamwork or education or discipline , the SOA initiative fails to
align its technology in support of the business.
63. SOA Project Delivery Approaches
and Planning
▷Top-down Approach
▷Bottom-up Approach
▷meet-in-the-middle Approach
▷Project and Lifecycle Stages
▷Service Oriented Analysis
▷Service oriented Design
64. SOA Project Delivery
Choosing a delivery approach is a critical decision
point because it represents a decision an organization
will usually need to live with for quite some time.
There are different project delivery approaches :
▷ Top-down Approach
▷ Bottom-up Approach
▷ Meet-in-the-middle
65. Bottom-up approach
▷ Tactically focused in that it makes the fulfillment of immediate business requirements a
priority and the prime objective of the project.
Pros and Cons :
▷ Avoids extra cost, effort, and time required to deliver services via a top-down approach
▷ Increased governance burden as bottom-up delivered services tend to have shorter
lifespans and require more frequent maintenance ,refactoring , and versioning.
66. Top-down approach
▷ Represent Spectrum Strategy view for enterprise.
▷ Advocates the completion of an inventory analysis prior to the physical design,
development, and delivery of services.
Pros and Cons :
▷ Demands more of an initial investment because it introduces an up-front analysis
stage focused on the creation of the service inventory blueprint.
▷ Service candidates are individually defined as part of this blueprint so as to ensure
that subsequent service designs will be highly normalized , standardized ,and
aligned.
67. meet-in-the-middle Approach ( Agile Delivery)
▷ Allows for an on-going analysis and definition of a service inventory blueprint, while
high-priority services are delivered in advance
▷ At a later point, after the analysis efforts have sufficiently progressed, services that
have been previously deployed are revisited
Pros and Cons :
▷ If necessary, they are then redeveloped and brought in alignment with the revised
blueprint.
68. Project and Lifecycle Stages
1. SOA Adoption Planning
2. Service Inventory Analysis
3. Service-Oriented Analysis (Service Modeling)
4. Service-Oriented Design (Service Contract)
5. Service Logic Design
6. Service Development
7. Service Testing
8. Service Deployment and Maintenance
9. Service Usage and Monitoring
10.Service Discovery
11.Service Versioning and Retirement
Common and primary stages related to SOA projects and the overall service lifecycle:
http://serviceorientation.com/soaproject/projectlifecycle
72. Primitive Service modeling process
Organize large amount of units of logic so
that they can be reassembled into
service-oriented solutions.
Group and categorize these units
according to the nature of their logic.
Focus on following SOA principles
1. Service reusability
2. Service composability
73. Primitive Service modeling process
Service
encapsulation
2
Non – agnostic
context
5
Agnostic
capability
4
Functional
decomposition
1
Agnostic
Context
3
74. process modeling [1. Functional decomposition]
Purpose : How can a large business problem be solved without having to build a
standalone body of solution logic?
Solution :
To apply service-orientation, we first must break down a business process by
functionally decomposing it into a set of desirable actions
Functional decomposition is Application of the separation of concerns theory.
75. process modeling [2. service encapsulation]
Purpose : How can solution logic be made available as a resource of the enterprise?
Solution :
Solution logic can be encapsulated by and exposed as a service (positioned as enterprise resource)
Solution logic capable of functioning beyond the boundary for which it is initially delivered
enterprise where individual solutions use logic encapsulated as services and vice versa ( as shared
services )
76. process modeling [3. agnostic context]
Purpose : How can multi-purpose service logic be positioned as an effective enterprise resource?
Solution :
Isolate logic that is not specific to one purpose into separate services with distinct agnostic
contexts
positions reusable solution logic at an enterprise level
Apply service reusability principle
77. process modeling [3. agnostic context]
Application :
Subset of the solution logic being further decomposed and then distributed into services with
specific agnostic contexts
Agnostic logic is defined and continually refined into a set of candidate service contexts.
form the basis of Entity Abstraction and Utility Abstraction
Impacts :
Increase quantity of services required to solve a
given problem
Leads to additional design considerations and
performance overhead associated with service
compositions.
The governance effort increased
Also the governance of the overall architecture is also
impacted as the quantity of agnostic services
within an inventory grows.
78. process modeling [4. agnostic capability]
Purpose : How can multipurpose service logic be made effectively consumable and composable ?
Solution : Agnostic service logic is partitioned into a set of well-defined capabilities that address
common concerns not specific to any one problem
81. process modeling [4. agnostic capability] Sample
Service definitions, each with capabilities that address processing
requirements of specific business process
After further service modeling, the definitions
are refined with agnostic capabilities.
82. process modeling [5. non-agnostic context]
Purpose : How can single-purpose service logic be positioned as an effective enterprise resource?
Solution :
Non-agnostic solution logic suitable for service encapsulation can be located within services
that reside as official members of a service inventory
83. process modeling [5. non-agnostic context]
Application :
▷ Non-agnostic service logic is shaped via the same governing design principles as agnostic
Services
▷ Most commonly applied in combination with Process Abstraction
▷ No rules as to whether this pattern should be applied before or after Agnostic Context
Impacts :
▷ Initial delivery will be more expensive and
more time-consuming
▷ The ultimate ROI can therefore be significantly
lower than with agnostic services