[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Capabilities vs. Services: "Partitioning" Our Reference Model?
A thought just popped into my head (scary, I know):
On the distinction between
capabilities and services...does it make sense to "partition" (using term
loosely) our reference model?
Why? Primarily for increased understanding, potentially efficiencies in usage.
What does this mean? We have the
following concepts in our current "puzzle" figure:
- Service
- Capability
- Service
Description
- Policy
- Execution
Context
- Exchange
- Visibility
- Interaction
- Real World
Effect
I believe we can group these into
those that pertain to "capabilities", and those that pertain to "services".
There will also be some in common (e.g. real world effect, which is discussed
for both capabilities and services), which we may perhaps relate somehow (i.e.
the services concept could be an extension of the capabilities concept, if it
makes sense). Here's how I see the groupings (for now I use the term "area"
instead of "group"):
CAPABILITIES
AREA:
- Capability
- Visibility
- Interaction
- Real World
Effect
SERVICES AREA:
- Service
- Service
Description
- Policy
- Execution
Context
- Exchange
We
can also visually depict these partitions in our abstract model figure (there
are multiple ways to do this). In the DRM, we have 3 "standardization areas"
(Data Description, Data Context, and Data Sharing), so these would be akin to
standardization areas for our reference model. We can also organize our spec
around them (i.e. "Capabilities Area" would be a section, as would "Services
Area", and each would discuss the concepts that are associated with that area).
I hesitate to call these "tiers" or "views", as that sounds too much like
architecture - but perhaps there are better terms to consider than
"area".
This partitioning may also provide value for future uses of our reference
model (e.g. reference architectures, process-oriented architectures, etc.) as it
lends a bit of modularity (again using loose terminology) that may yield future
efficiencies.
Is
this at least mildly worth considering?
Joe
Joseph
Chiusano
Associate
Booz Allen
Hamilton
O: 202-508-6514
C:
202-251-0731
Visit us online@ http://www.boozallen.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]