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

Continuous Integration with Visual C++ and COM

  William E. Caputo ThoughtWorks Oren Miller ThoughtWorks July 2002 The Continuous Integration principles are applicable in many different development environments. While the principles remain largely unchanged from project to project, the implementation of this practice can vary considerably. Variables such as language, platform, team size & team location provide unique implementation challenges. Here we will outline how we've implemented CI in a COM/Windows environment for a project developing primarily in Visual C++. The More Often the Better What Is a Successful Build? Single Source Point Building the Code Self-Testing Code Automated Build Dependency Management What We Could Have Done Better Summing up The More Often the Better As noted in the main article, one of the least intuitive notions about integration is that less often does not result in less difficulty, it results in more difficulty. This is especially true when developing with C++. The build time on a development...
Yorum Gönder
Devamı

Rotation

  Rotation I've spent a lot of time of the last year wandering around ThoughtWorks, talking to lots of people on lots of projects. One message that's come home really firmly to me is the value of rotation. We practice rotation in lots of ways. One of the most notable is rotating around countries. We've put in a deliberate program to encourage people to spend 6-18 months in a different country. Living a good length of time in a different country does a huge amount to widen people's perspective of the world. I've benefitted personally from living both in the UK and USA, even though they are very similar cultures. This mental expansion is even greater for those that spend time in somewhere like India, where the cultural differences are greater. Geographic rotation presents lots of challanges, particular for older people with familes. One of the things we need to figure out is how to make geographic rotation easier for people, so more people do it. Already there's a...
Yorum Gönder
Devamı

Business Capability Centric

 Business Capability Centric A business-capability centric team is one whose work is aligned long-term to a certain area of the business. The team lives as long as the said business-capability is relevant to the business. This is in contrast to project teams that only last as long as it takes to deliver project scope. For example, an e-commerce business has capabilities such as buying and merchandising, catalog, marketing, order management, fulfilment and customer service. An insurance business has capabilities such as policy administration, claims administration, and new business. A telecom business has capabilities such as network management, service provisioning and assurance, billing, and revenue management. They may be further divided into fine-grained capabilities so that they can be owned by teams of manageable size. Business-capability centric teams are “think-it, build-it and run-it” teams. They do not hand over to other teams for testing, deploying or supporting what they...
Yorum Gönder
Devamı