Label: policy_a2a

Content with label policy_a2a in KM: Service Oriented Architecture (SOA) (See content from all spaces)
Related Labels: policy_cs, policy_h2a, policy_acs

Page: P1. A service shall have one named owner
Motivation Ensure that a service is managed and governed sufficiently. An umanaged service can't be relied upon, and will not be successful. Argumentation If you are unable to find an owner for a service, chances are high that the service is unimportant which is not a good metric for success. Also if a service ...
Other labels: policy_h2a, policy_cs, policy_acs
Page: P2. A service shall provide documented business value
Motivation If the service does not provide business value, it will never be of any use/interest Discussion In establishing the business value of a service, we can easily add the Key Performance Indicator for the service, and automatically monitor the generated value against the target values ...
Other labels: policy_h2a, policy_cs, policy_acs
Page: P20. All services shall be in the service universe
Motivation Give the enterprise an understanding of the available services. Argumentation We want to prevent duplication of services. A simple and consistent access to service documentation. Library documentation of already existing building blocks to ensure usage/reuse of existing investments. Exceptions ...
Other labels: policy_cs, policy_acs
Page: P21. A service shall be categorized (OW SOA category)
Motivation Improve the quality and consistency of communication between the services. Ensure correct implementation of the services. Argumentation Since the service requirements vary a lot, it makes sense to categorize the services from a technical perspective to be able to pinpoint and standardize necessary technology to ensure ...
Other labels: policy_h2a, policy_cs, policy_acs
Page: P22. A service shall have an "authentication, authorisation, endpoint strategy"
Motivation Argumentation Exceptions/special cases Definitions OWSOA:SOA security and IAM Status Doc status H2A A2A ACS CS Last PAB discussion (/) () () () () 2007.06.08 PAB discussions DesignTime Governance SOA Design Rules FAQ
Other labels: policy_cs, policy_acs
Page: P23. A service shall document its Service Level Agreement SLA (response time, availabillity++)
Motivation Argumentation Exceptions/special cases Definitions Status Doc status H2A A2A ACS CS Last PAB discussion (/) () () () () 2007.06.08 PAB discussions DesignTime Governance SOA Design Rules FAQ
Other labels: policy_cs, policy_acs
Page: P3. A service shall do one only thing, and one thing well
Motivation We want to prevent service rot, duplication and loose coupled services, in other words good building blocks Argumentation If a service does more than one thing, it will likely not do everything well. The success ratio of a service correlates ...
Other labels: policy_h2a, policy_cs, policy_acs
Page: P31. A service shall provide for audit and monitoring of service usage
Motivation Argumentation Exceptions/special cases Definitions Status Doc status H2A A2A ACS CS Last PAB discussion (/) () () () () 2007.06.08 PAB discussions DesignTime Governance SOA Design Rules FAQ
Other labels: policy_cs, policy_acs
Page: P41. A service shall provide heartbeat and traffic monitoring
Motivation A heartbeat is necessary to be able pro actively react when a service is not responding according to SLA We want to keep track of the following: Does the service provide business value? Is the service functioning according to its SLA Where is a servicecomposition failing ...
Other labels: policy_h2a, policy_cs, policy_acs
Page: P90. A service shall have a documented coupling to the contractual and requirement for service usage
Motivation Argumentation Exceptions/special cases Definitions Producer Consumer requirement/contract Information requirements data quality (freshness, correctness, validness/timespan...) data usage rights (Licensing of data ) response time / availability usability o.l. peek (volume ...
Other labels: policy_h2a, policy_cs, policy_acs