When you’re SO focused on tech and coding, it can be easy to lose sight of the actual business goal and vision. You might start spinning your wheels, going off on tangents, and overall contributing to business inefficiencies - often without noticing. Not to mention, having to execute projects without a firm understanding of your place in the company’s vision and without a strategy for forward momentum can be downright frustrating and inefficient. ... How are data pros supposed to excel without strong leadership and frameworks to guide them in their execution? We need to make sure that as data implementation folks, we keep our eyes on the prize. And as leaders, we need to make sure data implementation workers are included in the overarching strategy from the get-go. If you’re ready to make sure the data projects you work on always stay on track and profitable, let’s dive into the data science process lifecycle framework. ... Essentially, the data science process lifecycle is a structure through which you can manage the implementation of your data initiatives. It allows those who work in data implementation to see where their role first comes into the bigger picture of the project, and ensures there’s a cohesive management structure.
Having a monolithic architecture does not imply that the system is poorly designed or bad. It does not say anything about quality. As the name suggests, it is a system designed in a modular way with exactly one deployment unit. Note that this is a purposefully designed and implemented modular monolith, which is different from an accidentally created monolith that grows over time. In a purposeful modular monolith architecture, every module follows the microservices principles. Each module encapsulates all the access to its data, but the operations are exposed and consumed as in-memory method calls. With this approach, you have to convert both microservices (Service A and Service B) into library modules that can be deployed into a shared runtime. You then make both microservices share the same database instance. Because the services are written and deployed as libraries in a common runtime, they can participate in the same transactions. Because the modules share a database instance, you can use a local transaction to commit or rollback all changes at once.
For something to be learned in a disagreement, both sides must be open to different perspectives. I once coached an engineer who had strong opinions and constantly found himself in decision gridlock. Team meetings became so tense that we couldn't get past even the first agenda item before the hour was up. This engineer was frustrated and wanted to know why he couldn't convince people of his ideas. My advice surprised him: he should allow himself to be convinced as much as he tried to convince others. When he applied this advice, it became noticeably easier to make progress in meetings. Because other team members felt respected, we were arguing less and focusing more on how to reach our goals as a team. When you focus solely on advocating for your own ideas, you are more likely to miss the critical points seen by others, however unintentionally. Having a collaborative mindset keeps disagreement healthy. A collaborative mindset means prioritizing the needs of the team or community rather than the individual. When these needs fall out of balance, having a shared purpose can recenter a team. It's not about being right; it's about doing right by the group.
What we continue to call technical debt is really the activities that are related to tending to and upgrading our software when third-party components are evolving or have common vulnerabilities and exposures (CVEs) and need to be upgraded. These are tedious, repetitive tasks that usually fall to the most experienced engineers as they require technical expertise to do correctly. Such activities can paralyze engineering organizations and are a tremendous burden on engineers; that often leads to burnout. Up to 30% of engineering time is spent on technical debt. The perception that somehow developers were responsible for accruing this technical debt and are doing something wrong that prevents them from keeping up is hugely demoralizing and demotivating. However, if we reframe technical debt as software supply chain management and stop blaming engineering for it, we can make maintenance more predictable and consistent. By taking steps like inventorying third-party components and determining how pervasive they are in the application, an organization can arrive at a maintenance estimate.
Theoretically, if organizations pay the ransom, the attackers will provide a decryption tool and withdraw the threat to publish stolen data. However, payment doesn’t guarantee all data will be restored. Executives need to carefully consider the realities of ransomware, including: On average, only 65% of the data is recovered, and only 8% of organizations manage to recover all data; Encrypted files are often unrecoverable. Attacker-provided decrypters may crash or fail. You may need to build a new decryption tool by extracting keys from the tool the attacker provides; Recovering data can take several weeks, particularly if a large amount of it has been encrypted; There is no guarantee that the hackers will delete the stolen data. The could sell or disclose the information later if it has value. Ransomware is a sustainable and lucrative business model for cybercriminals, and it puts every organization that uses technology at risk. In many cases, it is easier and cheaper to pay the ransom than to recover from backup. But supporting the attackers’ business model will only lead to more ransomware.
In the pandemic, open source has been critical. It has touched billions of lives, and it has saved lives. I saw this unfold daily at SUSE, which specialises in bringing open source software to business. I marvelled at the importance of universal access to critical code to design contact-tracing technology, helping unravel the complexities of the virus’s path across the planet. When Singapore led the world implementing contact-tracing, open source made it possible. When large-scale Covid-19 testing and analysis became available, open source made it possible (and we are proud to have empowered our customer, Ruvos, to achieve this). When healthcare organisations needed a cost-effective way to analyse torrents of data at a moment’s notice, open source made it possible. Open source pervades our lives. It is a remarkable, often unsung, force for good. Open source software is embedded in mammogram machines, it powers autonomous driving to make people safer on the road, air traffic control systems at airports, and weather forecasting technology to warn of storms and even earthquakes.
Practitioners on your team should investigate projects that have the potential to solve a “job to be done” for your business. What they turn up may need more time to bake before it can be used in a meaningful way at your company, but if a project isn’t immediately useful, star the repo and keep tabs on the project. More importantly, make sure your engineers have time to learn and try new things every week and even to contribute to open-source projects. It can do wonders for morale, retention, and recruitment, and if the open-source projects are ones that your business depends on, the benefits multiply. ... It’s easy to have more open-source tech in your IT organization than you realize. Using open-source software is often the easiest way for an engineer to add a feature to in-house software or fix a bug in third-party software. While open-source proliferation means your team is finding creative ways to solve business problems, you need to understand what technology is being used and how it affects your organization.
When it comes to revolutionizing digital infrastructure, the opportunity to increase sustainability and lower emissions lies directly with Enterprise Architecture (EA) teams and related disciplines. In short, the purpose of these teams is to create sustainable organizations delivering business objectives supported by modern digital platforms. This integrated perspective enables business and IT executives to quickly develop an understanding of where change is required and the impact this will have. So as we look to achieve the United Nations’ goals for sustainable development, EA’s overall targets should therefore include sustainable IT practices. A particular goal EA should help organizations achieve includes goal 9, which highlights the need to ‘build resilient infrastructure, promote inclusive and sustainable industrialization and foster innovation.’ Striving to achieve this goal won’t be a simple fix, but should certainly be seen as an opportunity for a profound, systemic shift to a more sustainable economy that works for both people and the planet.
Cybersecurity Risk Management: Are Your Enterprise Architecture and Security Teams Lacking Engagement?
The Digital Twin of an Organization (DTO) gives you a virtual representation of your organization, showing how the company performs as a system. It’s also a highly effective communication tool. With it, you’re able to visualize ongoing projects and see where they overlap. In addition, it tracks processes, systems, and information. The DTO modeling can be expanded with Scenarios. Using Scenarios, you can focus on various points to map out potential futures, including risk scenarios. From a risk management and security perspective, you can see what would happen if a critical system went down, which departments would be paralyzed, and how they could continue to function. For example, when mapping out the cybersecurity risk of ransomware hits, the Digital Twin of an Organization could give you a clear overview of which parts of the organization are most exposed and show how the attack could develop. Let’s say there’s a new virus affecting laptops that aren't fully patched. You can easily identify which parts have the most unpatched laptops.
Enterprise architects create holistic transparency and expertise across all layers, from business to IT and infrastructure landscapes. They also proactively identify the potential for optimization when it comes to business models and processes. The most important value that enterprise architects bring to the table is overseeing technology selection and the design of solution architecture. This showcases the increasing importance of enterprise architecture in shaping the agenda of CXOs (chief experience officers). Enterprise architects take a holistic approach in design, planning, implementation and KPI measurement. They are able to fully understand the business strategy and identify needed changes, as well as additional technological capabilities that are required. They not only indentify the requirements but can plan and implement them. This is done by being cognizant of the organizational strategy, business environment, stakeholder interests, constraints and risks. Finally, they ensure that the relevant outcomes are achieved or if course corrections are needed.
Quote for the day:
"Leaders must see the dream in their mind before they will accomplish the dream with their team." -- Orrin Woodward