Gregor’s Ramblings on Architecture - Enterprise Integration Patterns

This blog chronicles my journey with asynchronous and distributed system design over two decades. These are my Ramblings related to Architecture [See all Ramblings]. Subscribe to my ramblings via RSS.

Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.

The digital world is all about scalability: millions of web sites, billions of hits per month, more data, more tweets, more images uploaded. To make this work, architects have learned a ton about scaling systems. With everything around us scaling to never-before-seen throughput, the limiting element in all this is bound to be us, the human users. And the organizations we work in. One may wonder, then, why scaling and optimizing throughput in organizations is considered a very different field usually completely ignored by the IT architects. I feel that many of the scalability and performance enhancement approaches experienced IT architects know can be just as well used to scale organizations. If a coffee shop can teach us about maximizing a system’s throughput, maybe our knowledge of IT systems design can help improve the performance of organizations! Read more »

When you hitchhike through the galaxy, a towel will generally do. To ride the you need to be a bit better equipped. Riding the elevator up and down is exciting and provides tremendous value to the organization. But it is also demanding as you need to adjust to different audiences, backgrounds and dynamics, becoming a technology shapeshifter of sorts. To help with this transformation, I recommended a few books for each major section of the corporate high-rise. Read more »

As I recently observed, Corporate IT tends to be afraid of code: code is where all the pesky bugs come from, which have to be fixed by quirky, expensive, and unreliable developers or external consultants. This attitude plays to the favor of vendors who peddle products that "only" require configuration, as opposed to coding. Sadly, most configuration is really just programming in a poorly designed, rather constrained language without decent tooling or useful documentation. Being afraid of code and being unfamiliar with the modern development lifecycle is a dangerous proposition in a world where everything is becoming software-defined. Read more »

Corporate IT lives among zombies: old systems that are half alive and have everyone in fear of going anywhere near them. They are also tough to kill completely. Worse yet, they eat IT staff's brains. It's like Shaun of the Dead minus the funny parts. Read more »

I recently wrote about architects and the role they play in large organizations. Still, the question often remains what an architect should be doing besides "riding the elevator". Let's try another analogy: movie characters. Read more »

IT loves virtualizing stuff, following the old rule that in computer science every problem can be solved by just one more level of indirection. Cloud computing is based on virtualization of compute resources - you don't need to know which machine your application is actually running on and you can get new ones with the click of a button. Before cloud was a buzzword, though, VMware and others have virtualized machines at the operating system levels. Recently (in terms of buzz, not technology), containers bring another level of light-weight virtualization of resources. And let's not forget the Java Virtual Machine, which also claims a level of virtualization. What are we supposed to do with all these levels of virtualization? Read more »

Part of my job is to review system architectures. So I frequently ask teams to show me "their architecture", but almost as frequently I don't consider what I receive an architecture document. The inevitable question "what do you expect?" is also not so easy for me to answer: despite many formal definitions it's not immediately clear what architecture is or whether a document really depicts an architecture. One important test I apply is whether the document or the description contains any non-trivial decisions and the rationale behind them. Read more »

I have not blogged about events in a while, but SATURN 2015 has been an amazing event that's well worth rambling about. Read more »

Architects frequently play a critical role as connecting and communicating element between multiple parties. Especially in large organizations such communication is an important factor: too many parties speak different languages to convey different, and often conflicting, objectives. Many layers of management only exacerbate the problem as communicating to corporate leadership resembles the "telephone game" where a circle of kids relays a message one-by-one just to realize at the end that the message has completely changed along the way. Read more »

Defining what a software or IT architect is or does is no less challenging than defining software architecture itself. The SEI maintains a list of software architecture definitions, yet I have not seen a corresponding list for software architects. One could try to skirt the issue by declaring that software architects are the people who make software architecture. However, I think that this approach would be missing some important aspects of being an architect. Read more »

Happy New Year everybody! Over the holidays I tried to sort out some of my thoughts on Web services, SOA, architectural styles, coupling and all the other good stuff. I started to think about service-oriented architectures as an architectural style and how it compares to prior styles, such as distributed component architectures. Maybe it was the New Year's mood but I started to think that the evolution of architectural styles is a little bit like drunk driving... Read more »

Encapsulation and abstraction are the holy grail of today's software development. One of the great successes of hiding the implementation details under a common, abstracted interface are TCP/IP stacks. But as so often, overwhelming success can also have a flip side. Read more »