Ana içeriğe atla

Data Mesh Principles and Logical Architecture

 Data Mesh Principles and Logical Architecture The great divide of data What do we really mean by data? The answer depends on whom you ask. Today’s landscape is divided into  operational data  and  analytical data . Operational data sits in databases behind business capabilities served with microservices, has a transactional nature, keeps the current state and serves the needs of the applications running the business. Analytical data is a temporal and aggregated view of the facts of the business over time, often modeled to provide retrospective or future-perspective insights; it trains the ML models or feeds the analytical reports. The current state of technology, architecture and organization design is reflective of the divergence of these two data planes - two levels of existence, integrated yet separate. This divergence has led to a fragile architecture. Continuously failing ETL (Extract, Transform, Load) jobs and ever growing complexity of labyrinth of data pipel...
Yorum Gönder

Software Component

Software Component

The notion of changing software development from laboriously crafting code to building powerful systems by simple assembly of components has been a target since I entered our profession. It's target that is sometimes glimpsed, but never really attained - although many technologies have dangled the carrot of industrial reuse.

When we talk about software components, often the hardest step is to talk about what they are. My favorite definition is still this one

Components are not a technology. Technology people seem to find this hard to understand. Components are about how customers want to relate to software. They want to be able to buy their software a piece at a time, and to be able to upgrade it just like they can upgrade their stereo. They want new pieces to work seamlessly with their old pieces, and to be able to upgrade on their own schedule, not the manufacturer’s schedule. They want to be able to mix and match pieces from various manufacturers. This is a very reasonable requirement. It is just hard to satisfy

-- Ralph Johnson

I summarize this as saying that software components are things that are independently replaceable and upgradeable.

I look as components today as coming in two guises: libraries and services. A library consists of some code that is linked into a process at runtime, becoming part of the client process. Examples would include Java's jars, C#'s assemblies, Ruby's gems, and Javascript's modules. To be a proper component, the library user should retain the decision of when and whether to upgrade supplier libraries. So if I choose to use a 6 month out-of-date version of library, that's up to me.

A service is a component that exists in its own process, [1] clients talk to it over some interprocess communication mechanism: RPC, RESTful calls over HTTP, messaging, etc. Services may upgrade on their own timetable, without coordinating with clients, but to do this they must preserve their existing client contracts, so the client may choose when to upgrade their use of the service. For services to be components, you should never need to coordinate the upgrade of one service with another service.

I consider a component as a particular form of module. I define modules as a division of a software system that allows us to modify a system by only understanding some well-defined subsets of it - modules being those well-defined subsets. Components are a form of module, with the additional property of independent replacement.

Yorumlar

Yorum Gönder

Bu blogdaki popüler yayınlar

ActivityOriented

  ActivityOriented Any significant software development effort requires several different activities to occur: analysis, user experience design, development, testing, etc. Activity-oriented teams organize around these activities, so that you have dedicated teams for user-experience design, development, testing etc. Activity-orientation promises many benefits, but software development is usually better done with   OutcomeOriented   teams. Traditionally, big businesses with large IT departments (Enterprise IT) have tended to execute IT development projects with a bunch of activity-oriented teams drawn from a matrix IT organization (functional organization). The solid-lined arms of the matrix (headed by a VP of development, testing and so on) are usually along activity boundaries and they loan out “resources” to dotted-lined project or program organizations. Common justifications for doing so include: It helps standardization of conventions and techniques in development if a...
Yorum Gönder
Devamı

Out come Oriented

 Out come Oriented  effort, better sales conversion, greater customer satisfaction, i.e business outcomes. Outcome-oriented teams are those that are mandated and equipped to deliver business outcomes, such teams have people with the capability to carry out all necessary activities to realize the outcome.. By contrast,  ActivityOriented  teams are neither equipped nor mandated to do so. They can only perform one of several activities required to realize an outcome. A mandate to deliver a business outcome is very different from a mandate to deliver a certain amount of scope. Scope delivery is easy, relatively speaking. Outcome realization requires real collaboration between those who understand the problem and those who can fashion various levels of solution for it. Initial attempts at solution lead to a better understanding of the problem which leads to further attempts at better solutions. This doesn’t work where the product management organization is separate from t...
Yorum Gönder
Devamı

AlignmentMap

  Alignment maps are organizational information radiators that help visualize the alignment of ongoing work with business outcomes. The work may be regular functionality addition or technical work such as re-architecting or repaying technical debt or improving the build and deployment pipeline. Team members use alignment maps to understand what business outcomes their day-to-day work is meant to improve. Business and IT sponsors use them to understand how ongoing work relates to the business outcomes they care about. Here’s an example scenario (inspired by real life) that illustrates how these maps may be useful. A team of developers had inefficiently implemented a catalog search function as N+1 calls. The first call to the catalog index returned a set of SKU IDs. For each ID returned, a query was then made to retrieve product detail. The implementation came to the attention of an architect when it failed performance tests. He advised the team to get rid of the N+1 implementation. ...
Yorum Gönder
Devamı