Data Science, Machine Learning & API / SOA: Insights and Best Practices
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,819 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,302 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,360 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?