Data Science, Machine Learning & API / SOA: Insights and Best Practices
Ali_Arsanjani 120000D8QB Tags:  sustainable adaptive performance agile business_performance business 7,379 Views
Following the thread on Agile and Adaptive Business Performance and Optimization
Business Performance (BPer) is a measure of key performance indicators over a period of time. Within that period, we indicate there is BPer if the anticipated metrics and KPIs are exceeded by the actual KPIs.
For this to happen, Business Processes need to have been identified and engineered appropriately to achieve business goals measured by the KPIs.
The underlying Services that are orchestrated to produce the Business Processes should be selected or identified using a rationalized Service Identification method
(e.g., SOMA -- Service Oriented Modeling and Architecture) that encompasses the needs of various aspects of granularity, performance, agility, flexibility and complexity.
The Business Architecture should follow an agile and adaptive model to incorporate changes needed to accommodate sustained business performance and allow for continuous optimization.
Having an underlying Service Portfolio that allows the selection and combination of those services in nex contexts into Business Processes is one of the key factors in achieving and maintaining sustainable Business Performance.
I will discuss other factors in my next entries.
Greetings Dear Readers.
I would like to pose a question, to which I would like to invite your responses or further elaborations. Then we will discuss this in greater depth, as I begin to discuss my own views on this.
In your opinion how does a company achieve and maintain sustainable business performance?
What are the factors impeding the achievement of desired business performance?
When Service identification Becomes Critical: Service Proliferation Syndrome and Service Interface Changes
Ali_Arsanjani 120000D8QB Tags:  service_portfolio governance service_proliferation service_model service_monitoring soma 13,530 Views
As our industry continues to mature in the adoption of SOA and related technologies, we are witnessing not only the subsiding of hype but also, the emergence of new issues that are surfacing due to growing pains. These issues include the need to change service interfaces as they evolve in conjunction with changing business requirements. The service portfolio which is the single point of reference for an enterprise's business capabilities undergoes evolution with external and internal changes that are ongoing within and without the enterprise.
As the Service Portfolio, part of the Service Model, matures, changes to the service interface, and the service contracts are inevitable. I was approached with one solution: to put them under change control. However expedient this measure, it is not a cure, but temporary stabilizers of organizational turbulence. Changes to the underlying IT capabilities that reflect the business needs that are dealt with in a proactive manner tend to stabilize over time and yield the agility that helps power sustained business performance.
Properly designing the services, i.e., proper Service identification techniques and practices are paramount for alleviating these types of issues. Second best is to use a registry and repository to store and manage them centrally. And of course you need a source code control system to manage the code that is going to be using the services.
The use of correct Service identification for alleviating the risks and impact of Service Interface and Service Contract changes coupled with management and governance in a Service Registry and Repository are thus paramount.
Further, as services abound and the organization feels more comfortable in the creation of new or modified (see above) services, the need to manage and govern this Service Proliferation Syndrome becomes increasingly important. Again there are two aspects : one of which is doable at design time and another at runtime. Service Identification coupled with Service Refactoring and Rationalization (SRR) help mitigate the first aspect -- design time best-practices. Secondly, the monitoring of Services at runtime come hand in hand with the Service identification and Monitoring approach to alleviate Service Proliferation.
it is important to source IT constructs that directly support the business goals and processes. In order to do so we will explore the six fundamental constructs of service-oriented architecture. Elevation of the notion of the service or service interface and later on the service contract from a programming construct to the level of an architectural abstraction was a key paradigm shift in software engineering. By the service does not stand alone. It needs to be implemented using some component. The data has to be passed to the service to the component back to the databases and data warehouses and information systems in the backend, processing needs to be completed information retrieved and returned to the requester of the service. Thus information is paramount for services. As a service proceeds with its processing there are certain rules that apply. The invocation of the service should be a more intelligent invocation than that of the method on an object. Generally speaking it is common practice to invoke a method on an object without the necessary cards and without the necessary application of rules. It is typically left up to the application logic to implement those rules. With service-oriented architecture is important to although externalize the rules pertaining to a service but make the application of those rules visible to the service consumer or service requester. The service is also governed by a set of policies that allow the service to be changed without having to fundamentally change the implemented capability behind the service. Services should not only respond to a direct invocation but should be able to respond automatically in a subscriber will fashion to the triggering of that even
Thus it is critical to understand the six fundamental constructs of service-oriented architecture: services, processes, components, information, rules and policies and events. Services can be a comic or composite. As they participate as the steps of the business process, services can be invoked at each one of these steps allowing a shared set of common services to be utilized in a BPM context. therefore, processes are also one of the fundamental constructs of SOA.
Your architectural description should capture these six constructs as you meander through the journey of the software development lifecycle.
also, note that all of the six constructs are motivated by business level constructs. The following diagram establishes a relationship tween the business constructs and the corresponding SOA paradigm constructs.
A lot of market buzz is going on around BPM (business process management). This is a resurrection of one of the buzzwords of the earlier decade. However this time, it is BPM powered by SOA. Service-orientation is the underlying factor that will make a big difference in BPM. Rather than Business Process Management being solely about the management and optimization or re-engineering of business processes in traditional workflow contexts, with SOA, the activities the underlying orchestrated process (composite services) can be flexibly changed within a shorter duration, provided governance is fine with the change, and thus enable a greater degree of business agility.
Over the years as I have taught, designed and implemented software architecture the question I have been asked over and over again has been:
What is Architecture?
According to the Arsanjani view of Architecture :-), the Architecture of a system is the holistic view of the relative configuration of a set of static and dynamic elements that include what I call the 6C's :
Components -- what are the structural building blocks of a solution, or a style of architecture, of the elements that can be combined to produce a larger structure
Connectors -- The components need to connect with one another, whether statically (as in an Entity-relationship kind of relation) or dynamically, as in a composition in an SOA, where you may have orchestration or choreography.
Constraints -- The constraints on the connectors and/or components that provide rules of engagement of what is permissible and what is not.
Composition -- How to compose or what are the valid compositions of components
Context -- the context of invocation of a component is critical to the designation of how that component will behave
Containers -- the components must live in some runtime container that will provide uniform life-cycle management capabilities for them
Traditionally, the first three have been the main focus in universities and textbooks. But the latter three that I have added seem to be essential to a more complete depiction of the operational or actionable perspective on software architecture.
Let me know what you think.
Ali_Arsanjani 120000D8QB 4,863 Views
To engage in an eco-system, you need to sense the environment, the eco-system. Business sensors gather business significant events and apply business policies to see what actions need to be taken as they sense a threat, an advantage, a change in the business climate, in the eco-system architecture.
Thus, to measure business performance and monitor business agility, you need what I am coining as "business sensors".
Ali_Arsanjani 120000D8QB 7,449 Views
Architectural Paradigms of the Future Part 2: Eco-system Architecture engulfs Enterprise and Business Architecture in the Cloud
Ali_Arsanjani 120000D8QB Tags:  service-oriented-architec... enterprise-architecture business-architecture eco-system-architecture 14,419 Views
In the context of a cloud formation, where is the "enterprise", per se? Of course it exists in the traditional sense. And so does enterprise architecture. But in the context of a cloud, which may span private, public and hybrid instances, where is the "enterprise" now?
Rather than a physical location, the enterprise now seems to be more nebulous and "logical" or "conceptual". It now can be seen to expand possibly, with the cloud, as the amorphous mass expands so does the virtual enterprise. This is where the enterprise merges with the eco-system and you see the emergence and need for addressing aspects of the eco-system that span physical and logical enterprises. As we needed enterprise architecture, for the cloud we need an eco-system architecture.
Eco-systems are more dynamic, opportunistic in some instances; some shorter and some longer enduring alliances between interested business parties. This not only affects the IT side, as it were, in a "bottom up" fashion, but also the business architecture; in a more "top down" manner.
The structure and function of a business is defined by its model of what goods and services it provides and consumes; who it needs to partner with at what point in its dynamic existence. This relates to policies that cut across and senses the eco-system for more appropriate alliances and takes competitive advantage of this new configuration. A business architecture in an eco-system architecture is then configured by rules and policies driven by competitive business goals, not statically defined.
The cloud provides a virtual rockbed for the reconfigurable enterprise that supports its dynamic business architecture to sense and respond, anticipate and adapt to the ebb and flow of trends in the eco-system. The eco-system architecture defines and configures these elements that include the traditional business architecture, multiple enterprise architecture plus a set of rules, policies, that define desirable (to be sought) and undesirable (to be avoided) configurations of the business and IT as they ride on top of the virtual infrastructure provided by the cloud.
This constitutes the eco-system architecture of the future.
As the eco-system of business evolves into a more opportunistic convergence of business partners into an eco-system of value, similar to the notion of a value chain, but a more loosely coupled exchange of goods and services, the need is increasingly being felt for an upfront design of an architecture structure to enable smooth and measurable business operations.
Eco-system architecture defines the foundation of interaction between a set of semi-autonomous business entities that interact with each other using a set of configurable policies that define the valid business interactions among potential and prospective participants, such as business partners: providers, consumers and brokers.
Eco-system architecture extends Enterprise Architecture in a similar way that EA extends the notion of solution architecture. EA is analogous to "city planning" whereas ECSA is analogous to planning how the economy of the whole nation is structured through a set of rules, policies, standards and structures .
Even though SOA has been around for years, the community at large did not have a clear declaration of intent and "values", although individually, there appeared to be a large degree of consensus. Formalizing this consensus, a group of seasoned SOA practitioners got together recently and agreed to a high level declaration of intent.
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
That is, while we value the items on the right, we value the items on the left more.
We follow these principles:
© 2009, the above authors, this declaration may be freely copied in any form, but only in its entirety through this notice.
We have just published the SOA Manifesto . This document helps guide the values and principles of service-orientation and service-oriented architecture.
"Service orientation is a paradigm that frames what you do.A set of 6 values are then outlined, followed by a set of 14 principles that help guide the implementation of the values.
When faced with the forces outlines in the value statements, we provide a preference for one rather than the other, even
though both may be viable under certain circumstances.
I will post links to other authors of the manifesto soon.
The IBM Service-oriented Modeling and Architecture(TM) (SOMA) is IBM’s end to end software development and integration method (aka, process life-cycle) based on service-oriented software engineering principles to produce enterprise and individual project-level SOA or non-SOA solutions. This method includes prescriptive guidance applicable during the phases and iterations required in a software development process life-cycle. This guidance includes the activities and tasks to be performed by various designated roles within the life-cycle requiring input work products and producing or updating output work products and deliverables at specified junctures within the life-cycle. The tasks leverage a set of techniques (“capability patterns”) that prescribe and promote the use of best-practices included in the method, in conducting and accomplishing the task and to instantiate the related work products and deliverables.
SOA enables business agility. It enables flexibility of IT systems that support the business architecture. As the business changes, the IT systems required to support the business in a volatile environment of competitive engagement, are less prone to change.
The history of software engineering started with the separation of functionality or processing and data. The data of the processes that manipulate the data were traditionally separate. There came a time when as the pendulum swung emphasis was placed more on the data in one era ended and the pendulum would swing and emphasis would be placed more on process. Eventually object oriented programming, which evolved into object-oriented design and object oriented analysis, played a key role in the unification of process and data. David Parnas was the first to suggest the notion of information hiding. The notion of information hiding was that access to information or access to data was strictly done through the functionality provided by an object. Those that object encapsulated its data and protected it from direct manipulation. It offered a set of operations that you could perform on the data, but you could only invoke those operations do not access the data directly.
Objects often reflected real-world objects. The identity of the real world object was used as an abstraction and implemented in a software system as a software object. Identity often corresponded to a real-world entity although helper objects evolve from the IT constructs necessary to implement the real-world construct in a computer system.
One of the most important principles of object oriented programming was based on a separation of concerns not only in the domain of abstraction but also in terms of separation of interface from implementation. Not only did we separate data from the operations that manipulated the data all in one object, but we did so one step further by separating the interface of the behavior from the actual implementation of that behavior. The behavior or rather its implementation, actually change the state of the object or as it were manipulated the data directly. However, there must be several ways in which we can implement this data manipulation. Even though there may be several ways in which we can implement this manipulation, there is typically one way to represent the interface or the externally visible signature that would be used by a consumer to request a change to be made to the data that the object owned.
This principle is called programming to interfaces rather than implementation.
These interfaces coupled with the notion of composing a set of similar objects that often had interdependencies among them into the next level of encapsulation which was called the component lead to a whole new era of -based development. It exported interface and could contain multiple objects all of which would typically be expected to be related to one another in some logically cohesive fashion. These objects were expected to be highly collaborative with one another and thus made sense to be called located within the packaging of a single component. This allowed not only manageable functionality but also decrease the risk that nonfunctional requirements would be violated.
The promise of object orientation
What is Cloud Computing? Similar to the Initial era in which SOA was trying to be defined, we are now in the era of more definitions. That is not in itself a negative thing, but a necessary part of the formation of new technology as they become mainstream.
Cloud computing is essentially an extension of SOA and service oriented computing. It provides concentrated infrastructure, platform and data center like capabilities offered at a set of services over the Internet. The cloud has several unique characteristics.
The cloud itself needs to be viewed from both a consumer and a provider perspective.
from the perspective of the consumer they are looking for a service-based delivery model over the web in which a highly reliable efficient self optimizing and feed your head up infrastructure capability are made available to them.
From a Provider perspective, the cloud involves two key aspects of self optimization and virtualization using a service-based delivery model.
The service-based delivery model can operate under one of the following kinds of services: platform as a service, software as a service an infrastructure as a service.
in order to connect the consumer with the provider, the provider must publish in some metadata standard information interchange format the quality of service that it can provide and the services that it can provide, so the service consumer can select among various provider of various services they provide and the various qualities of service that are offered for each type of service.
Could computing is fundamentally a service delivery model. It is instantiated by an architecture that provides the services and is consumed by a Service Consumer's own internal systems.
cloud computing is a
service delivery model
in which a virtualized set of
are offered by Cloud Service Providers with the choice of quality of service.
Service Consumers then have a choice
as to what provider to select
Further more, the model should support a seamless portable view of service such that services
from multiple providers can be choreographed by a consumer or broker without having to
know about the inner workings of the underlying cloud infrastructures.
What do you think?