Application Architecture

Architecture Beyond Domains

by

Enterprise Architecture has been around for decades. The discipline has profoundly shaped how organizations plan, align, and structure their strategies, systems, and operations.
Frameworks such as the TOGAF Standard define four architecture domains and link them to specific architectural roles. While this approach has helped organizations organize work, it has also unintentionally reinforced rigid silos and limited the true potential of architecture as a holistic organizational capability.

The post Architecture Beyond Domains appeared first on EAWheel.

To Be A Platform, Or Not To Be A Platform?

by

That is the question! If you’re the CEO of your business, or maybe the Chief Digital Officer (CDO) responsible for digital business strategy, it’s the central question you need to be asking of your leadership team. A platform business can t…

Observations on NRF 2018. Making Retail Great Again

by

The National Retail Federation’s Big Show attracted tens of thousands of attendees . Far from resigning themselves to conquest by market places they are determined to make the right investments to thrive and survive. Three years ago we found retail CIO…

Microservices or Monoliths – Fences and Neighbors

by

  At the end of my last post, “What Makes a Monolith Monolithic?”, I stated that I didn’t consider the term “monolithic” to be inherently derogatory. It is, rather, a descriptive term relating to the style of organizing an application’s architecture. Depending on the context the system operates within, a monolithic architectural style could lie […]

What Makes a Monolith Monolithic?

by

  It seems like everybody throws around the term “monolith”, but what do we mean by that? Sam Newman started the ball rolling yesterday with this tweet: My first response was a (semi) joke: I say semi joke because, in truth, semantics (i.e. meaning) is critical. The English language has a horrible tendency to overload […]

Stopping Accidental Technical Debt

by

In one of my earlier posts about technical debt, I differentiated between intentional debt (that taken on deliberately and purposefully) and accidental debt (that which just accrues over time without rhyme or reason or record). Dealing with (in the sense of evaluating, tracking, and resolving it) technical debt is obviously a consideration for someone in […]

Microservices, Monoliths, and Modularity

by

  There are very valid reasons for considering a microservice architecture (MSA) when building/evolving an application. In my opinion, however, forcing modularity isn’t one of those very valid reasons. Just the other day, I saw tweet from Simon Brown saying this same thing: I still like his comment from two years back: “I’ll keep saying […]

Pragmatic Application Architecture

by

I saw a tweet on Friday about a SlideShare deck that looked interesting, so I bookmarked it to read later. As I was reading it this morning, I found myself agreeing with the points being made. When I got to the next to the last slide, I found myself (or at least, this blog) listed […]

Strategic Tunnel Vision

by

  Change and innovation are topics that have been prominent on this blog over the last year. In fact, Greger Wikstrand and I have traded a total of twenty-six posts (twenty-seven counting this one) on the subject. Greger’s last post, “Successful digitization requires focus on the entire customer experience – not just a neat app” […]