Website Technology Profiler

{
  "PageContent": "<h3>Eltjo’s Digital Architecture Blog | Digital architecture for the agile age</h3>Over the past 18 months, we have been iteratively developing a way to assess maturity with respect to architecture in an agile context. We did this together with a number of client organizations that were interested in improving their architecture function. I will be sharing some insights from this development in upcoming blog posts. This first insight is about balancing the responsibilities of architecture work, to avoid getting lost in either the Waterfall Wasteland or the Agile Outback.The nature of architectureThe\r\nperception of what ‘Architecture’ should mean in the context of software\r\nengineering has gone through a number of changes since it was first used in\r\nthat context. The\r\noriginal 1990s perception views architecture as a set of structures that\r\nrepresent an abstraction of a system being delivered – needed to deal with the\r\ngrowing complexity of typical software systems. In that view, the main\r\nresponsibilities of the architect are to create (visual) models of the system,\r\nand to use those models to validate the architecture.In the\r\nearly 2000s, a second perception emerged, with a new responsibility focus:\r\narchitects needed to make important decisions in order to create the right\r\nmodels of their solutions (‘right’ meaning that they fulfill their\r\nstakeholders’ needs). If ‘abstraction’ and ‘structures’ describe what the architect creates, the decision\r\nmaking refers to how they create.Around 2010, partly under pressure of the agile movement’s focus on business value, a third perception was proposed: the why was added to the what and the how of architecture. This view shed light on the goal of architecture: to improve organizations’ control over risk and cost – not only during design, but extending the architects’ responsibility to the fulfillment of the solution.The list of\r\narchitecture responsibilities would not be complete without the one\r\nprerequisite without which the architect would be unable to fulfill any\r\nresponsibility: understanding the context of the solution, meaning the\r\nstakeholders, their needs, and the environment in which the solution is to be\r\ndelivered. So we end\r\nup with five responsibilities of architects (or of the ‘architecture function’\r\nof organizations): understanding context, making decisions, modeling,\r\nvalidating and fulfillment of the solution. These five responsibilities also\r\nmap very nicely to Philippe Kruchten’s “Things architects really do”,\r\nto Eoin Woods’ “Architectural\r\nfocus areas” and to the RCDA practices we have been applying for years.DependenciesIt is\r\nimportant to note the many dependencies between the five responsibilities\r\nidentified above. Just to mention a few: modelling\r\nand decision making without understanding context will lead to wrong models and\r\ndecisionsmodelling\r\nactually implies decision making (about decompositions, relationships, etc.)if\r\nthere are no models and no decisions, there is nothing to validatefulfillment\r\nof unvalidated decisions and models leads to troubleSo\r\nfulfilling the five responsibilities in isolation is not enough: they should be\r\nfulfilled in a coherent way.Good architectureSince architecture\r\nis context, there’s no such thing as good\r\narchitecture in an absolute sense: the best one can hope for is an\r\narchitecture that fits the\r\nstakeholder needs in its context. In my experience, the best fitting\r\narchitectures result from paying proper attention to all five responsibilities mentioned above. This is not easy; due to\r\nmostly cultural pressures, dogmas and misconceptions, many organizations ignore\r\nsome of the responsibilities, resulting in a flawed architecture function. Two\r\nextreme examples are the Waterfall Wasteland and the Agile Outback caricatures\r\ndescribed below.Paying proper attention to all five responsibilities, however, does not mean always paying equal attention: depending on the context, modeling may indeed require more attention than decision making, and validation may be more critical in some situations than in others. \r\n\r\nWhen talking to teams, architects and stakeholders in different organizations, we started to notice some interesting patterns in the way they took up these responsibilities. We created caricatures to identify those patterns, and called these caricatures the Waterfall Wasteland and the Agile Outback. \r\n\r\nThe Waterfall WastelandIn the\r\nWaterfall Wasteland, the architects live in an ivory tower. They ignore the\r\ndecision making and fulfillment responsibilities, which they consider to be\r\nsomeone else’s. They have a very clear job description: to create perfect\r\nmodels and validate them against stakeholder needs. If the resulting solution\r\nis unsuccessful, it’s obviously not their fault. The idea that they would be\r\nresponsible for decisions or share responsibility  for successful delivery is abhorrent to them:\r\nit would mean that their success would depend on the capability of others, and\r\non their ability to cooperate…The Agile OutbackIn the Agile Outback, teams usually don’t have architects (although they might use euphemisms  like ‘pathfinder’ or ‘master builder’). Modeling is studiously avoided, since “The best architectures…emerge from self-organizing teams”, and doing modeling might offend the agile gods and disturb the ‘magical’ emergence process. Similarly, validating designs is considered a waste of time: failing early and often is a much quicker way to learn and improve.Essential architecture skillsThe five responsibilities\r\nof architects are a good basis for deriving the essential knowledge and skills\r\nof the architect:For\r\nunderstanding context, we need analytic skills to identify the\r\nenvironment and stakeholders of our solution, communication and social skills\r\nto understand stakeholder needs and knowledge\r\nmanagement skills to cultivate and share that understanding.For\r\nmaking decisions, we need decision making skills like making trade-offs and prioritizing. We also need extensive knowledge\r\nof the relevant architectural tactics and\r\nstrategies in our (business and technology) domains.For\r\nmodeling, we need creative skills for visualizing our design, and knowledge of relevant modeling languages and techniques like decomposition and composition.For\r\nvalidating, we need analytic and trade-off skills (again), and knowledge about techniques for risk management, cost estimation and making business\r\ncases. To\r\nfulfill our fulfillment\r\nresponsibility, we need leadership\r\nskills like communication, convincing, listening and anticipation.\r\nBut we also need to know a bit about the economy\r\nof delivering software-intensive systems and the relevant software lifecycles.Looking at\r\nthis list, it is no surprise that good overall architects are very rare. It\r\nmight be a good idea to spread these responsibilities over a number of people,\r\nand create an architecture function\r\nin an organization: a (possibly virtual) team made up of members with complementing\r\nskills and knowledge. ConclusionArchitecture has five responsibilities: understanding context, making decisions, modelling, validating and fulfillment. Organizations need to pay proper attention to each of these responsibilities; what is ‘proper’ depends on the context. Dogmatically denying some of the responsibilities will lead teams astray into the waterfall wasteland or the agile outback. The breadth of knowledge and skills needed to fulfill these responsibilities is substantial, and hard to find in one individual; it almost always takes a team to produce good architecture.(Image from Pexels at Pixabay)",
  "Url": "https://eltjopoort.nl",
  "IpAddress": "185.104.29.166",
  "ReverseDns": "web0166.zxcs.nl",
  "Asn": null,
  "Http2": false,
  "Http3": false,
  "ResponseTimeMs": 1982,
  "StatusCode": 200,
  "ServerHeaders": [
    "Apache",
    "PHP/8.3.25"
  ],
  "Ssl": {
    "Issuer": "CN=R12, O=Let's Encrypt, C=US",
    "Subject": "CN=eltjopoort.nl",
    "NotBefore": "2025-11-25T03:32:00-08:00",
    "NotAfter": "2026-02-23T03:31:59-08:00",
    "SubjectAltNames": [
      "DNS Name=eltjopoort.nl",
      "DNS Name=mail.eltjopoort.nl",
      "DNS Name=www.eltjopoort.nl"
    ],
    "Hsts": false,
    "Ciphers": [],
    "Protocol": "Tls13",
    "DaysUntilExpiry": 22
  },
  "Cdns": [],
  "HostingHints": [],
  "Cms": [
    "WordPress",
    "WordPress (robots.txt)"
  ],
  "Frameworks": [
    "React",
    "jQuery"
  ],
  "JsLibraries": [],
  "Analytics": [
    "Google Analytics GA4"
  ],
  "AdsAndMarketing": [],
  "PaymentGateways": [],
  "EcommerceHints": [
    "Magento",
    "PrestaShop"
  ],
  "SocialSignals": [
    "Twitter"
  ],
  "MediaProviders": [
    "YouTube"
  ],
  "SeoTags": [
    "content-type: text/html; charset=UTF-8"
  ],
  "HtmlLanguage": "en",
  "HasRobots": true,
  "HasSitemap": true,
  "SecurityHeaders": [],
  "CookiesObserved": [],
  "XhrApiHints": [],
  "SitemapCounts": {
    "total_urls": 4
  },
  "ChatWidgets": [],
  "ABTesting": [],
  "PrivacyConsent": [],
  "EmailMarketing": [],
  "WebFonts": [
    "Google Fonts"
  ],
  "DynamicJs": [
    "jQuery (script Resource)",
    "Server Technology: PHP/8.3.25",
    "Web Server: Apache",
    "React (CDN Detection)",
    "jQuery (CDN Detection)",
    "jQuery (Script Analysis)",
    "ES6+ JavaScript Features"
  ],
  "ResourceHosts": [
    "eltjopoort.nl",
    "platform.twitter.com",
    "gmpg.org",
    "fonts.googleapis.com",
    "",
    "imgs.xkcd.com",
    "pbs.twimg.com"
  ],
  "CssFrameworks": [],
  "BuildTools": [
    "Vite"
  ],
  "ServerTech": [
    "PHP (inferred from WordPress)"
  ],
  "DatabaseHints": [],
  "PageTitle": "Eltjo&#8217;s Digital Architecture Blog | Digital architecture for the agile age",
  "MetaDescription": null,
  "ImageCount": 16,
  "ScriptCount": 10,
  "LinkCount": 13,
  "Errors": [],
  "UiFrameworks": [
    "D3.js",
    "Vuetify (Class Names)",
    "Angular Material (Class Names)",
    "Ionic (Class Names)"
  ]
}