The future of system architecture
So far, the primary effect of any API-first mandate has been to make developers ensure they document their APIs and publicize them. But a major thrust of the Amazon API-first mandate was to reduce the costs incurred from developing duplicate capabilities in multiple systems. Because most enterprises do not update all their systems every few years, any API-first mandate will take time to show real effects in the enterprise. But over time, those effects will make themselves felt, especially when an API-first mandate is combined with a reuse-before-build mandate that requires system developers to reuse capabilities available in the enterprise before building new ones. As more systems make their capabilities available through APIs, and development teams are tasked to reuse before building, there will come a point at which building new systems is replaced by recomposing existing capabilities into new capabilities. The amount of duplication across systems with widely varying purposes is surprising. Most systems need a way to store and retrieve data. Most systems need a way to authenticate and authorize users. Most systems need the ability to display text and render graphics.
Is this the future of retail? 7-Eleven launches checkout-free store
Australia’s largest convenience retailer is making a move on checkout-free, launching a “cashless and cardless” concept store in Richmond, Melbourne today. The store will allow customers to pair their cards with a smartphone app, scan items with their cameras, and then walk out. It’s a similar system to the one trialled by Woolworths in Sydney last year and follows the success of Amazon’s no-checkout grocery stores in the US. 7-Eleven chief executive Angus McKay said he’s on a mission to push the envelope on convenience retailing. “We’re trying to push the notion of ‘convenience’ to its absolute limit,” McKay said in a statement circulated on Wednesday morning. “In the new concept store, customers will notice the absence of a counter. The store feels more spacious and customers avoid being funnelled to a checkout location creating a frictionless in-store experience,” he said. The announcement follows a trial run out of an Exhibition Street store in Melbourne, although 7-Eleven hasn’t detailed plans for any further expansion of the concept as yet.
How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
As more data becomes ubiquitously available, the ability to consume it all and harmonize it in one place under the control of one platform diminishes. Imagine just in the domain of 'customer information', there are an increasing number of sources inside and outside of the boundaries of the organization that provide information about the existing and potential customers. The assumption that we need to ingest and store the data in one place to get value from diverse set of sources is going to constrain our ability to respond to proliferation of data sources. I recognize the need for data users such as data scientists and analysts to process a diverse set of datasets with low overhead, as well as the need to separate the operational systems data usage from the data that is consumed for analytical purposes. But I propose that the existing centralized solution is not the optimal answer for large enterprises with rich domains and continuously added new sources. Organizations' need for rapid experimentation introduces a larger number of use cases for consumption of the data from the platform.
The Intersection of Innovation, Enterprise Architecture and Project Delivery
Peter Drucker famously declared “innovate or die.” But where do you start? Many companies start with campaigns and ideation. They run challenges and solicit ideas both from inside and outside their walls. Ideas are then prioritized and evaluated. Sometimes prototypes are built and tested, but what happens next? Organizations often turn to the blueprints or roadmaps generated by their enterprise architectures, IT architectures and or business process architectures for answers. They evaluate how a new idea and its supporting technology, such as service-oriented architecture (SOA) or enterprise-resource planning (ERP), fits into the broader architecture. They manage their technology portfolio by looking at their IT infrastructure needs. A lot of organizations form program management boards to evaluate ideas, initiatives and their costs. In reality, these evaluations are based on lightweight business cases without broader context. They don’t have a comprehensive understanding of what systems, processes and resources they have, what they are being used for, how much they cost, and the effects of regulations.
When algorithms mess up, the nearest human gets the blame
“While the crumple zone in a car is meant to protect the human driver,” she writes in her paper, “the moral crumple zone protects the integrity of the technological system, at the expense of the nearest human operator.” Humans act like a “liability sponge,” she says, absorbing all legal and moral responsibility in algorithmic accidents no matter how little or unintentionally they are involved. This pattern offers important insight into the troubling way we speak about the liability of modern AI systems. In the immediate aftermath of the Uber accident, headlines pointed fingers at Uber, but less than a few days later, the narrative shifted to focus on the distraction of the driver. “We need to start asking who bears the risk of [tech companies’] technological experiments,” says Elish. Safety drivers and other human operators often have little power or influence over the design of the technology platforms they interact with. Yet in the current regulatory vacuum, they will continue to pay the steepest cost.
The Death of Enterprise Architecture: defeating the DevOps, microservices, ...
Current application theory says that all responsibility for software should be pushed down to the actual DevOps-style team writing, delivering, and running the software. This leaves Enterprise Architect role in the dust, effectively killing it off. In addition to this being disquieting to Enterprise Architects out there who have steep mortgage payments and other expensive hobbies, it seems to drop out the original benefits of enterprise architecture, namely oversight of all IT-related activities to make sure things both don't go wrong (e.g., with spending, poor tech choices, problematic integration, etc.) and that things, rather, go right. Michael has spoken with several Enterprise Architecture teams over on the changing nature of how Enterprise Architecture help in a DevOps- and cloud-native-driven culture. He will share their experiences including what type of Enterprise Architecture is actually needed, tactics for transitioning and when it's best to just kill off Enterprise Architecture and let the DevOps cowboys run wild.
Address goals with various enterprise architecture strategies
Enterprise architecture can also revolve around important application decisions, rather than a diagram of software stacks. In the context of software architecture, decisions include the programming language, platform, type of cloud services used, CI/CD systems involved in deployment, unit tests, the data-interchange format for the API, where the APIs are registered and related systems. For some programmers, the term architecture means a look at just the highest level of design: a set of domain objects that interrelate, such as customer, order and claim. Another view of enterprise architecture in the technical realm revolves around quality attributes. These attributes must exist for the software to work, but are unlikely to fit in a specification document. Examples include reliability, capacity, scalability and security -- even things such as uptime, measuring and monitoring levels, rollback approach, delivery cadence, time to build and time to deploy. Quality elements are not functional requirements, per se, but are ways to determine acceptable operating conditions and necessary tradeoffs to get there.
What You Need to Know about Programmable Logic Controller (PLC)
Nowadays, dedicated pieces of software have been developed for the PC in order to help with PLC programming. Once the program is written, it is then downloaded from the computer to the PLC with a special cable. In the old days, up until the mid-1990s, PLCs were programmed by using either special purpose programming terminals or proprietary programming panels. Often times, they had function keys which represented the logical elements of PLC programs. As far as storing goes, programs would get put on cassette tape cartridges. A popular form of programming is ladder logic, which is the most widely used one. It features symbols (as opposed to words) in order to emulate relay logic control, with the symbols being interconnected by lines, representing the flow of current. As the years went on, the number of symbols available has increased, thus increasing the level of functionality that PLCs have.
Tala and Branch both seek to offer microlending over mobile devices in developing countries. The US-based companies make real-time loan decisions dynamically by using every piece of information they can gather from the customer’s mobile phone; public reports note that the companies use text messages, contacts, and hundreds of other data points to make underwriting decisions. A new set of companies are developing demographically-focused products. They segment not only from a brand and marketing perspective, but from a product innovation perspective as well. For example, True Link Financial’s elder fraud protections, Finhabits’ saving focus for Latino’s, Camino Financial’s lending for Latino-owned small and medium size businesses, or Ellevest’s product design for women all go beyond branding to design products from scratch with unique use cases and features in mind. Similarly, Brex offers cards tailored individually for startups, for ecommerce companies, and (reportedly) for other small business segments.
Five-Step Action Plan for DevOps at Scale
To give you a practical example of how these steps come together, consider the story of a large manufacturing enterprise with which we had the opportunity to work. They began their enterprise DevOps adoption with a pilot project in which they migrated their database to an AWS data lake. The project quickly showed how DevOps could create greater scalability to support the data demands of the manufacturer’s IoT applications. The manufacturer’s Center of Excellence leveraged this initial success to apply DevOps and digital transformation across company’s various departments, applying the model above to departments like enterprise architecture, application development and even business units like credit services. With the initial pilot project focused on a well-defined migration to AWS, the outcome has been the company’s agile adoption of DevOps for greater security, cost efficiencies and reliability. The idea of enterprise DevOps at scale can be daunting -- especially for large enterprises with complex systems, complicated processes and a great deal of technical debt.
Quote for the day:
"Leadership does not depend on being right." -- Ivan Illich
