Pavithra,
My point is that Enterprise Architecture is not configuration management and has never been. But many people practice configuration management and call it EA. Segment architectures are only a logical outcome of having defined all of the resources aligned
with capabilities across the organization - to discover common sets and alignments.
Yes, the current practice of identifying segments is widely discussed in the gray literature. However, the current practice of identifying segments before you've done extensive capability modeling - in my humble opinion - is flawed. I have seen organizations
struggle with this approach - trying to tackle it too early. The "segments" generally focus again on sets of technologies, and do not encompass people, data, information resources. Segments of resources cannot be discovered without doing extensive capability
modeling. You don't need to go to the business process level at all to do that. In fact, it gets in the way of seeing future segments. All you see is current segments.
Best regards,
Denise
From: Pavithra [pavithra_kenjige@xxxxxxxxx]
Sent: Thursday, March 14, 2013 10:39 PM
To: BEDFORD, DENISE A.D.; Ontology Summit 2013 discussion; Hans Polzer; 'Ian Bailey'
Subject: Re: [ontology-summit] Capability
Denise,
Enterprise Architecture moved further then configuration management, in each subject area ( business line) became segment architecture to support business lines across organization, for example administration capabilities and core capabilities..
The example came from HBR article that Ian had sent. Such techniques are used in business process engineering.. to improve business process, which came before enterprise architecture.
I guess we are deviating from this group's objectives ie "Ontologies"!
Thanks in advance,
Pavithra
From: "BEDFORD, DENISE A.D." <dbedfor3@xxxxxxxx>
To: Pavithra <pavithra_kenjige@xxxxxxxxx>; Ontology Summit 2013 discussion <ontology-summit@xxxxxxxxxxxxxxxx>; Hans Polzer <hpolzer@xxxxxxxxxxx>; 'Ian Bailey' <ian@xxxxxxxxxxxxxxxx>
Sent: Thursday, March 14, 2013 9:30 PM
Subject: RE: [ontology-summit] Capability
Pavithra,
I totally agree with Ian. It absolutely cannot be a process. In your example, Vendor Management may be a function but it is not a capability. The capability would focus on why you want to manage vendors. Instead that might be - Ensure Product Sourcing
(or something like that). Vendor management may be a sublevel 3 capabillity as there are many other ways to source products. If you define your capability at Vendor Management, you'll never see opportunities for doing product sourcing differently. You're
stuck in the present, and the only improvements you'll make will be small, incremental ones that won't really have an impact. It all depends on why you're doing enterprise architecture.
If you're doing EA to manage technology, you might better do configuration management. Anytime I see a spaghetti diagram presented as an enterprise architecture, I know there really isn't any design work going on -- its all about configuration management.
If you're doing EA to align all your resources with your business goals (think future), then you need to start with capabilities, document current state resource alignment, get all the stakeholders in the room to agree on what future state looks like at the
business level, and realign your resources.
Best regards,
Denise
From: Pavithra [pavithra_kenjige@xxxxxxxxx]
Sent: Thursday, March 14, 2013 10:08 PM
To: BEDFORD, DENISE A.D.; Ontology Summit 2013 discussion; Hans Polzer; 'Ian Bailey'
Subject: Re: [ontology-summit] Capability
Denise,
Thanks for being specific. In Walmart example, the capability " aggressive vendor management" is a business process with a future state where as "Vendor Management" would be a function. But clarification sake, it is easier to do a functional decomposition
first.. then work with business process. Because process has to apply to something.. and functions are visually more concrete. Even though they are different kind of modeling.
But Ian said a capability can not be a process?? So what do you have to say about that?
Pavithra
From: "BEDFORD, DENISE A.D." <dbedfor3@xxxxxxxx>
To: Pavithra <pavithra_kenjige@xxxxxxxxx>; Ontology Summit 2013 discussion <ontology-summit@xxxxxxxxxxxxxxxx>; Hans Polzer <hpolzer@xxxxxxxxxxx>; 'Ian Bailey' <ian@xxxxxxxxxxxxxxxx>
Sent: Thursday, March 14, 2013 8:57 PM
Subject: RE: [ontology-summit] Capability
All,
Sorry to come into this discussion late, and my apologies if I am off target. I teach Business Architecture in our new School of Digital Sciences. In the context of enterprise architecture a capability is defined as what an organization does to deliver
value to its stakeholders. The purpose of identifying and documenting capabilities in Business Architecture is to ensure that ALL of the organizations resources are being leveraged to support the business goals. This means people, data, information, applications
and lastly technology. In fact, technology (not applications) in the capability modeling and resourcing process is only aligned with applications and generally not directly linked to capabilities. All of the classification/matrix models align with capabilities,
except for technology which only aligns with applications.
Capabilities are only associated with business processes at sublevel 2 or 3, and then only for the purpose of critically evaluating whether they actually support a capability. But, capabillities are not the same thing as a business function. If you approach
capabilities as a function, you will not be able to surface redundancies and variations across the organization.
If you approach capabillities as you do a function, you will not be able to see the future state - you anchor on what is. The same problem with focusing on business processes - taking a bottom up view always anchors you in the present.
Apologies if this speaks to a question you're not discussing.
Best regards, Denise
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [ontology-summit-bounces@xxxxxxxxxxxxxxxx] on behalf of Pavithra [pavithra_kenjige@xxxxxxxxx]
Sent: Thursday, March 14, 2013 9:42 PM
To: Hans Polzer; 'Ontology Summit 2013 discussion'; 'Ian Bailey'
Subject: Re: [ontology-summit] Capability
,
Hans,
Ian provided a link to an HBR article. A part of that article discusses "capabilities-driven strategy"
"Let’s look at Wal-Mart to see how a capabilities-driven strategy works. Most attribute the chain’s success to its impressive logistics operations or its ability to get vendors to fall in line. But having one or two superior capabilities is not enough. What
really underlies Wal-Mart’s competitive advantage is a system of mutually reinforcing capabilities that lowers total value chain cost in a differentiated way. The giant discount retailer achieves maximum efficiency by integrating four capabilities: aggressive
vendor management, expert point-of-sale data analytics, superior logistics, and rigorous working-capital management. Every one of these capabilities reinforces the others and supports the company’s strategic purpose to deliver “everyday low prices” to consumers
"
In Enterprise Architecture, for Business Architecture, one has to develop, the mission, vision, goals and objectives, which would address similar strategic planning. Capabilities, support such goals & objectives. One of the purpose of developing Enterprise
Architecture is to increase operational efficiency by using technology to support your business.
When you have to develop systems to increase operational efficiency, in support of the business, and have to incorporate the capabilities, the capabilities would become Internal business functions and would have internal business requirements with measurements
in place..
Thank you,
Pavithra
From: Hans Polzer <hpolzer@xxxxxxxxxxx>
To: 'Pavithra' <pavithra_kenjige@xxxxxxxxx>; 'Ontology Summit 2013 discussion' <ontology-summit@xxxxxxxxxxxxxxxx>; 'Ian Bailey' <ian@xxxxxxxxxxxxxxxx>
Sent: Thursday, March 14, 2013 7:59 PM
Subject: RE: [ontology-summit] Capability
Pavithra,
The issue regarding terms such as “capability” and “enterprise” is that they are often used to convey implicit context and scope. But the
context and scope is best left to a separate set of modifiers (or dimensional specifiers). You’ll note that the “C” in the name of the NCOIC “SCOPE” model stands for “Capability”. The point of doing that was to highlight that all of the terms in the SCOPE
acronym are usually associated with implicit scope, but they really don’t specify any explicit scope by themselves. For example, an enterprise can be something that an individual embarks upon, or even just the individual him/herself. But of course, most people
use the term “enterprise” to convey a fairly large scale entity or activity, something on the order of hundreds or thousands of people, say, or even larger. Similarly, the term capability as used in today’s session primarily originated in the defense domain
to convey large scale ability/potential to accomplish operational mission objectives (the airplane “performance envelop” example used being actually a fairly small-scale illustration of that usage). Of course, you are correct that in a more constrained scope
context, capability might be a feature of a specific product or system (other words contributing to the SCOPE acronym). SCOPE was intended to serve as a semi-quantitative framework for describing (or exploring/investigating/eliciting) the scope of any such
entity or activity (the “O” in SCOPE being “Operation”, but it could be “Ontology” with a little bit of modification), rather than relying on people intuiting some particular scope from the term used to represent the entity or activity implicitly.
Hans
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Pavithra
Sent: Thursday, March 14, 2013 6:26 PM
To: Ian Bailey; Ontology Summit 2013 discussion
Subject: Re: [ontology-summit] Thank you.
Ian,
I don;t want to repeat, but in
In general for software development, a capability is a "feature" or a " function" or a "service" that the product or software is capable of providing. As you said, it is used at a strategic level and later mapped to requirements and systems and so forth.
An use case specifies the usage. It is developed in futuristic way to help the designers to capture how that "feature" or a " function" or a "service" be used by the users ( actor or system when automated) and the behavior of the product or software.
It is developed during detail requirement stage!
Scenarios should capture all different ways that "feature" or a " function" or a "service" can be used and exceptions and error handling.
Test cases should include all the scenarios with unique sets of data to capture all possible types of input and exceptions and error handling.
Matrices are developed based on the correct behavior of the test cases .. 0 tolerance is one such matrix.
It was part of RUP development life cycle.. . Rational Rose developed Use case modeling initially. They also supported Object Oriented Modeling and UML. hope that helps.
Thanks,
Pavithra
Folks,
The concept of capability as a tool for strategic planning originates in the military. I think McKinsey did the original work on this in the 90s for UK MOD and also some
work in US DoD. Capability is explicitly NOT about process. The whole idea is to allow strategic thinking without resorting to design of processes. Capabilities should be expressed in terms of outcomes - what, not how. Once you've worked out your capabilities,
you can think about the processes and systems needed to deliver the capability. The concept has now found much wider use in the commercial world - see http://hbr.org/2010/06/the-coherence-premium/ar/1 and it also seems to have found a home in IT for portfolio
management and application rationalisation, though whether those guys stick to the process-independence rule is somewhat questionable.
It's a very tricky concept to model in an ontology. In IDEAS we take the approach that a capability is the set of all possible things that are capable of achieving a particular
outcome. Capabilities can have measures of effectiveness which constrain the members of the set. This approach seems to work for military architectures and strategic acquisition planning. We then have the concept of a capability configuration (people, systems
and processes) that deliver the capability (these become subtypes of the capability) and finally fielded capabilities - physical things that are instances of the capability configuration and also therefore instances of the capability. MODAF works this, and
I think DoDAF does too.
Chris Partridge did a lot of work on this for us - esp. around the dispositional aspects of capability.
Regards
Model Futures Limited is a company registered in England and Wales with company number 05248454
Registered Company Address: 1 Nelson Street, Southend-On-Sea, Essex, SS1 1EG
VAT Number: 848 7357 75, D-U-N-S Number : 73-998-0352
MOD FATS 4: FATS/4/MFL, DGFM Supplier Code: 56945
Hello,
Thank you again.
Regarding the discussion about "Capability", I would like to add my two sense to it here.
A capability can be translated as a function or service that meets certain set of requirements as defined by stake holders/organization/interested parties . If it is accomplished or performed by an "actor" or another "system" it can be written as use
case or multiple use cases. Scenarios can be used to handle multiple dimension of the capability. Even tho use cases look simplistic, they are not necessarily that simple, the scenarios can handle complexities to certain level..
Thanks,
Pavithra
to the organizers for the opportunity to present (which gave the the opportunity to develop the ideas a bit further).
to the participants for their questions, they will help make the next communication better.
RPI Tetherless World Constellation
Center for Technology in Government iChoose Ontology Development team
for being great collaborators and for the opportunity to work on IChoose (CTG)
happy to answer questions, and happier to guide and develop the GOEF framework if you think you would find it useful.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Joanne S. Luciano, PhD
Tetherless World Constellation
Research Associate Professor Rensselaer Polytechnic Institute
Deputy Director, Web Science Research Center 110 8th Street, Winslow 2143
Office Tel.
+1.518.276.4939 Global Tel.
+1.617.440.4364 (skypeIn)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (01)
|