Data Science Process Lifecycle
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.
Distributed transaction patterns for microservices compared
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.
How disagreement creates unity in open source
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.
Microservices Adoption and the Software Supply Chain
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.
When it Comes to Ransomware, Should Your Company Pay?
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.
Open source for good
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.
5 principles for your cloud-oriented open-source strategy
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.
Enterprise architecture and the sustainability puzzle
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?
.png?width=1500&name=ardoq-content-SecurityMonth(2).png)
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.
How To Leverage Enterprise Architects As CXO Advisors
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
No comments:
Post a Comment