We often hear phrases like "change is a constant" or "the pace of change and the threat of disruption creates tremendous opportunities," as Steve Case said. Even though we know this to be true, many practitioners seem to design and develop business applications and systems to a fixed set of point-in-time requirements.
Software development invites the need for continuous redevelopment of business applications to address new opportunities. Yet a hidden side effect of continuous integration/continuous delivery (CI/CD) is that it can give developers permission to create bad solutions and continually fix them as an accepted best practice. However, the approaches that agile software development teams and squads typically use aren't the only approaches available. Architects can and should do better at addressing how we design for change.
We recently led a workshop at The Open Group's Enterprise Architecture Practitioners Summit about employing architectural thinking for uncertainty. We believe that preparing for uncertainty starts with rethinking typical practices for developing code and crafting databases. Technology is not always the only issue that needs solving. Solving through thinking or, in our case as architects, architectural thinking, encourages architects to rethink the discipline of creating a business application.
Don't be afraid to think outside the box
We urge architects not to give in to adopting best practices that aren't serving the IT practitioner and the organization for the long term. So many best practices are best practices in name only.
[ Learn more strategies to gracefully make changes to teams, processes, and tech for a successful digital transformation. ]
We believe that architects already have the credentials and capabilities required to help address this challenge for organizations, and architectural thinking is a way they can showcase their mettle and value to the organization. However, architects also need to ensure they don't overly constrain themselves by leaning back too heavily on some of their existing coping mechanisms, including:
- Setting a hard scope boundary
- Reducing scope coverage to a minimum
- Simplifying the constituent components of the solution to basic common constructs
- Reducing the time horizons for planning
- Redacting content to allow simple comparisons
These are, however, all extremely valid as coping mechanisms—they allow us as architects to consider and work on solutions effectively. But the point to be made here is they are also self-imposed and can constrain both the way we work and the outcomes if we adopt them through "muscle memory" without consciously considering the consequences.
Three ideas about uncertainty to keep in mind
You'll have to open more than your eyes to see clearly. Here are a few key points that help architect for change:
- Uncertainty is not a primary concern or interest. Architects can demonstrate their mettle by leading the way forward in critical thinking by unwinding unnecessary constraints within the organization.
- Uncertainty is complex. IT practitioners invariably like to work with requirements. Working with something definitive is easier. Discussing a change that someone in the business needs next year can be abstract and daunting. The activity may even appear fruitless. But, if change is inevitable, we must begin to provide the space for change and start to use adaptive techniques.
- When you learn how to address uncertainty, you'll always be one step ahead. It's easiest to think of an organization in a stochastic manner, as if it's another number in a larger equation, not a predictable sequence of events.
For instance, your favorite software project, solution, or app, is probably no longer on version 1.0. That implies that every business application has been revised. A revision shouldn't have to mean a code change. A new version or dot-release is the result of a code change. Other techniques can be used to reduce the amount of coding revisions. Thinking about addressing uncertainty starts to bring some of these techniques to the forefront.
[ Learn how tech leaders are rethinking work to maintain momentum on digital transformation. ]
Reevaluate how you approach uncertainty
We hope this helps you rethink how to approach uncertainty and practice some self-evaluation by ensuring you aren't redacting beyond usefulness.
저자 소개
Neal is an IBM Distinguished Engineer and a Distinguished Open Group Information Architect. He is a CTO in IBM Consulting covering government, education, healthcare, and life sciences. Neal has a deep level of experience in creating adaptable software solutions.
Neal has recorded many of his insights in several books, including Smarter Data Science (2020), Viral Data (2009), Enterprise Architecture (2003), and Conceptual Modeling Language Syntax and Semantics (1999). He is currently working on an artificial intelligence (AI) business book titled A Matter of Consequence. He has been a distance-learning instructor for the University of Washington, a guest lecturer at Thomas Jefferson University, and a guest teacher for the Forest Hills school district in Grand Rapids, MI. Neal holds several patents and has had articles published in multiple technical journals and blogs.
유사한 검색 결과
Bridging the gap: Red Hat Academy shaping open source talent in APAC
From banking to tech: Bradley's Red Hat journey
Where Coders Code | Command Line Heroes
The Sysadmin And The Script | Compiler: Re:Role
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래