Resumo do artigo A Business-Oriented Foundation for Service Orientation de Ulrich Homann
De acordo com as definições atuais de orientação a serviços, estes oferecem funcionalidades acessíveis por rede através de padronizadas interfaces. Estas características principais prometem pelo menos interoperabilidade de protocolos independente de plataforma, provedor ou localização.
Atualmente, entretanto, resolver problemas de integração técnica não é suficiente por si próprio para justificar o investimento em orientação a serviços. Para reforçar o argumento, diz-se muito sobre apoio de orientação a serviços à agilidade do negócio porque, em um ambiente orientado a serviços, as soluções são mais fáceis de serem construídas compondo-se serviços, reconfigurando-os e os reutilizando. Isto talvez proceda, mas pela atual definição de orientação a serviços, muitos negócios devem implementar orientação a serviços e ainda assim prover o apoio a TI que o negócio precisa ou deseja.
Para justificar um investimento em orientação a serviço, entretanto, precisa-se endereçar os problemas que possam vir em todo projeto empregando novos princípios arquiteturais:
- Como impedir que a orientação a serviço siga iniciativas prometedoras similares nos mesmos erros arquiteturais que ocorreram no passado?
- Como ter certeza que a arquitetura escolhida para implementação relaciona-se com os requisitos de negócios?
- Como maximizar a expectativa de vida de implementação em um ambiente sempre renovado?
Para conseguir satisfazer tais objetivos, propõe-se entender os negócios como uma rede de capacidades. Uma capacidade modela o que uma função de negócios faz - seu comportamento visível (contra como ela o faz, seu comportamento interno) - e o nível esperado de performance. Pagar empregados e enviar produtos são exemplos de capacidades. Estas capacidades têm "proprietários" e "clientes" em uma forma genérica e o que espera-se que eles façam a um certo nível (como unidades por período de tempo, ou outra medida de qualidade). Isto é "o que" é feito e o nível que é feito. Dentro das capacidades há especificidades de como aquela capacidade é implementada a um dado ponto em tempo com respeito a pessoas, procedimentos, tecnologia e assim por diante. A este nível de abstração, nós focamos em aspectos externos, e como eles são atingidos não é importante. A capacidade é essencialmente uma caixa preta.
O que um modelo deve ter, afinal:
In other words, modern businesses cross traditional corporate boundaries in multiple dimensions, and it only makes sense that our modeling and solutions account for this. The corporate boundary is becoming analogous to the fiscal year for a company when it comes to planning. Both are important and relevant boundaries, but businesses have to plan and budget beyond these boundaries.
Evolução dos sistemas:
Systems Evolution - Connected Environment of Business Functions
If you examine the systems of any given company and look at what they do, you generally will find that the systems or applications support specific functionality or user communities. Finance systems for the finance community, customer relationship management (CRM) for the marketing, sales, and support communities, and so on. If they are connected at all, the connections are not very elegant. The result is that customers live with disconnected silos of functionality. The unpleasant fact for them is that in all likelihood it will stay that way, as new ways of doing business emerge faster than integration can occur.
O que é uma business capability?
Business Capabilities - A More Stable Foundation
So, we find that the real question is "When you architect a solution for your customers, which elements of that architecture are really durable and allow you to deal with change?" Because that answer obviously provides the best ROI and the best insurance against architectural obsolescence.
What we have found is that the stable elements are much more about what businesses actually do (for example, create purchase orders, generate invoices, ship products, and so on). These business activities, which we refer to as business capabilities, are relatively stable, but how businesses implement them with people, procedures, and technology, and how those activities knit together into processes, is far less stable. So now, we need to find out what a business does, what its capabilities are.
Before we continue, let's introduce a few definitions for our discussion:
* A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome. A capability describes what the business does (outcomes and service levels) that creates value for customers; for example, pay employee or ship product. A business capability abstracts and encapsulates the people, process/procedures, technology, and information into the essential building blocks needed to facilitate performance improvement and redesign analysis.
Como são alinhadas as capacidades:
Capabilities - The Optimal Problem Solving Layer
We propose modeling the business as a structured—as opposed to a physically integrated—network of capabilities. This addresses the "rich interconnection" over which other aspects (such as the way technology is applied) can be layered from the start instead of added as an expensive and cumbersome afterthought. As you can see, this aligns closely with the black-box service-orientation model: Business capabilities are the structural elements (black boxes) that provide a stable foundation aligning service-orientation projects with their business drivers.
Capabilities Expose Interfaces
One of the most important aspects of capabilities is how they relate to other capabilities; thinking about capabilities in context of the ecosystem is really thinking about their connections. Thus, early detection of their connections to other capabilities, or essentially defining the interrelated ecosystem, is also a crucial step in understanding which boundaries can be traversed and which cannot, a crucial step for maximizing any re-architectural efforts. In fact, discovering these connections may be as valuable as defining the capabilities, because you manipulate and manage the connections, while the capabilities remain essentially unchanged black boxes.
Divisões das capacidades:
Level 1 Foundation Capabilities, subdivididas em
Operational Capabilities - Capabilities—regardless of provider of any given capability—that are required to deliver the value identified as the goal of the business
Environmental Capabilities - Environmental Capabilities address the capabilities outside the basic operations of the business that either influence value delivery (e.g., expectations of customers, compliance requirements by governments, or competitive capabilities by existing or emerging suppliers), or offer opportunities to leverage the ecosystem (including customers) for value delivery/differentiation.
Level 2 Capability Groups
Capability Groups are the next level in the capability model. For example, within the core capability "1. Develop Products/Services" there is often a capability group called "1.1 Plan Products/Services." The Product Engineering group that plans products may further consist of a number of capabilities at level 3…n where specific capabilities and their attributes are described.
A capability group is often an important initial level for doing analysis because it is at the capability group level where service levels, impediments and constraints, and organizational ownership/accountability can first be abstracted and made actionable.
Level 3 Business Capabilities
Capability groups are decomposed into business capabilities. Business capabilities are the building blocks for the business capability mapping. Business capabilities can be decomposed into more granular business capabilities. There are detailed attributes that are captured at the business capability level. Within the analysis you may decompose some business capabilities to very detailed levels (Level 4 and beyond) and aggregate other capabilities at Level Three. It is not necessary to decompose all capabilities to the same level.
Conclusão a melhor forma de
* How do we prevent service-oriented architectures from following similar, hopeful initiatives into the same architectural mistakes of the past?
* How do we ensure that the chosen implementation architecture relates to the actual or desired state of business?
* How do we prolong the life expectancy of the implementation in an ever-changing environment?
é:
The key point to take away is that service-orientation with Web services is only the implementation of a particular model. It is the quality and foundation of the model that determines the answers to these questions. Business capabilities give you a frame of reference to pose these questions and answer them for the various interconnected viewpoints in your business. It finds the stable elements of business to model your architecture around and provides a critical layer that closely aligns to service-orientation. service-orientation in turn supplies the compartmentalized, but connected, structure to implement capabilities so that IT meets the actual business requirements and provides a truly agile business.
