Label: policy_acs

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

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_a2a
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_a2a
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_a2a
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_a2a
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_a2a
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_a2a
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_a2a
Page: P30. A service shall have a versioning strategy (ACS, CS)
Motivation When a serviceconsumer starts using a service, a dependency to that service's contract is created. The service's contract can't undergo any major changes without this having an impact on the serviceconsumer. This introduces the need for several versions of a service. Argumentation Services evolve ...
Other labels: policy_cs
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_a2a
Page: P32. A service shall document its Service Level Agreement SLA (response time=30ms, availabillity=99.995%)
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