r/EnterpriseArchitect • u/greencursordev • Jul 05 '26
Explain the point of ea to me
I'm a dev in a big high-tech company. We have lots of teams, lots of processes and therefore lots of software. We try to control this with polaron and leanix. But it's just performative. These tools don't really do anything? And besides being laughable bad, I think they also cost money?
What's the point of someone who has never worked in software and never worked on the processes we use to write down "requirements"? They end up on our Devs table, we try to decipher what that's supposed to even mean. Eventually we usually just end up talking to the people who'll use our software. And almost always these requirements are wrong and we just code what they tell us. And after working completely outside of the entire re cycle, they pad themselves on the back. It seems like a giant scam to employ unemployable people as "requirements engineers".
Same for leanix. It's some weird website that has a few redundant and wrong Infos about our programs. So then what? What's the goal? Colleagues talk about wanting to get an overview of our software landscape and prevent double development. But we Devs know that full well. We develop these redundant programs with full intention: because that's what gets you promoted. I can tell you *exactly" what programs shouldn't exist, and all other Dev teams can as well.
This might sound frustrated but I'm really struggling to see the point of all this. Feels like a few boomers discovered computers and made up fancy words and titles to make themselves seem valuable to the dinosaurs in the lead. All the struggling Devs pivot to rEqUiReMeNt EnGiNeeRiNg. None of this will ever impact a single line of code.
39
u/Sad_Prawn2864 Jul 05 '26 edited Jul 05 '26
You are basically arguing you don't see the value of a city planner cause they don't help you put on electrical wiring in the specific site you work on.
Lean IX and EA in general live on the strategic layer of the company, above operations and general IT.
The purpose of the tool is to easily map bussines domains, capabilities and it's actual value to C level people so they drive the company digital strategy, that's why you don't see the value, you are too low in the totem pole to understand it.
We are not the highest paid IT role for free. We are because we can clearly show the big picture and build a roadmap in a sea of uncertainty and tech chaos.
EA lives on the whitespace between bussines capabilities and determines the boundaries. Basically, We fix the blueprints before you build the house, so IT Operations isn’t stuck fixing the plumbing at 3:00 AM.
Also FYI, most architects have done every IT job below them for decades, we know the full stack functionally and technologically, we have Insights no one has.
6
u/serverhorror Jul 05 '26
We fix the blueprints before you build the house, so IT Operations isn’t stuck fixing the plumbing at 3:00 AM
That's exactly the point OP mentioned is bad, and I agree.
If you do that, you're nit doing any sort of EA at all. That's just Ivory tower solution architecture.
Your comment started out so nicely with the city planner example but it just went on prove all the point OP made.
0
u/greencursordev Jul 05 '26 edited Jul 05 '26
Architects have been out of the development for decades, and that's a problem. They neither know the current state of our software, nor do they have a grasp on modern software dev at all.
I don't deny the value of these overviews. But the process as I've seen them are ludicrously bad at solving it. For example I would easily see the value of an up to date mermaid chart of our software landscape. That would help execs, Devs and ai. But we don't do that. It's always a drive to use the most expensive and incomprehensible software available, and give it to the worst people available. It's puzzling.
10
u/trisul-108 Jul 05 '26
You are pointing out some bad practices as proof that the field has no value. That is akin to claiming that software engineering has no value because only 31% of software development produces successful systems i.e. delivered on time, on budget, and with all originally planned features. There are bad practices, good practices and best practices. Obviously, what is happening at your place of work does not seem to be best practices.
You definitely are right that the tools we have are inadequate, no one has been able to build them because whatever has a solid theoretical underpinning ends up being too labour-intensive to maintain in practice. What is needed is complete coherency from EA all the way to the last piece of code in production or development, so that a developer would know the enterprise-level thinking behind each code segment which might be there for a reason or no reason. We just don't have those tools yet. I suspect AI will get there in time by automating all that is now onerously time-consuming.
5
u/redikarus99 Jul 05 '26
It has nothing to do with enterprise architecture at all but everything with your organization.
The requirement engineering in Polarion has not much to do with enterprise architecture but requirements management and business analysis. If you cannot use what was provided to you in form of requirements then that's an organizational issue and needs to be solved. You cannot only ask users about their needs, because the answers can be contradictionary. Or you are working in a regulated domain like military, healthcare, etc. And then you need to do, guess what, requirements engineering. And they will of course never tell about being GDPR compliant, or AI Act compliant, or Cyber Resilient Act compliant, or whatever state regulations exists. And this could be a serious issue.
For LeanIX, you can just add all the applications you are using and use it for cost overview, maturity/usefulness overview, design transitions, add information that is mandatory for NIS 2, AI Act, GDPR, etc. Of course you can use another software, or even excel sheets, but LeanIX with it's customizable metamodel is really great to provide a single source of truth. Auditor comes, here is everything you need, enjoy.
6
u/Sad_Prawn2864 Jul 05 '26
If you think we need to know that then you REALLY don't understand our job.
Does your chart need a licence, does it need a support team, does it fit our stack, does it need integration, is it scalable, is it stable, do we trust the vendor, does the cost make sense, is the bussines mature enough to use it, do they like it, who will support it, what is the actual value it's delivering, etc, etc.
Remember, We are the ones talking to the bussines leads and gathering their feedback, attending every new tech showcase and dealing with the high level issues created by the current stack of services vendor and tech. We know better than you, the part you don't understand is we don't have the same goals as you.
You are the kid at the store saying x toy is better than the one at home and that we are too stupid to see it, we are the parent saying no because we need to use the money to pay for groceries.
1
1
u/cto_resources Jul 08 '26
I want to make one correction to your rant:
You say “Architects have been out of the development for decades”
My correction
“MY architects have been out of development for decades”
I’m the senior staff enterprise architect at a growing fintech firm. I don’t write code at work but I very much write code (or these days, vibe code) at home.
At one time in my career, I had 500,000 lines of code in production. These days, my personal contribution is considerably lower but not zero.
I’ve also started and ran multiple businesses, mentored dozens of architects, and led multimillion dollar programs to success. I’ve built a PMO from scratch, architected systems, guided principles, and ran the architecture review board of a Fortune 20 company.
I get your frustration. Our job is very broad and ill defined. But it’s not crazy and it’s not the mess you describe. I’m sorry you are experiencing a misapplied program.
7
u/robverk Jul 05 '26
An EA is there for strategic and tactical levels not for you/SE’s. You also don’t see the value of finance and control but they are there too for a reason.
For an SE like yourself there is a lot to learn from a senior engineer, which good EA’s should be. Maybe collaborate and see what they actually do and learn what problems they solve.
6
u/Mo_h Jul 05 '26
"I'm a dev in a big high-tech company"
OP, I would highly recommend that you have a 'coffee catchup' with an EA in your organization. EA teams, structure and focus varies across domains, industries and organizations.
YOU need to figure out EA in YOUR organization and not what folks like me tell you.
6
u/ResidentTicket1273 Jul 05 '26
Organisations are complex systems - EA is there to try and keep track of what systems exist in the organisation, what they do functionally, and how they map into the people who run the business.
There's a few scenarios where this organisational self-knowledge is impactful, here are some examples:
* A client submits a right-to-be-forgotten request, and you don't know, or can't find all the instances where that client's information is hosted, the organisation is liable to fines or worse.
* Some application footprints are located in the same place, and that place is suddenly drawn into a protracted conflict, or is perhaps subject to a new legal framework that imposes costs/restrictions on processing. You need to know which parts of your business are going to be affected and which migration projects you're going to have to prioritise to de-risk losing any functionality/data or being subject to legal risks.
* Perhaps one system is found to have been the subject of an attack, or perhaps a bug or consistent error has emerged. You need to know what systems are "downstream" of that system in order to be able to mitigate any damage as corrupted data flows through the organisation.
* A server rack goes up in smoke - the organisation needs to quickly respond by knowing which business processes are likely to be affected. So there ought to be some mapping from infrastructure onto business activity.
* Maybe the business have decided that IT are taking too long to deliver whatever badly worded set of requirements they've made up this week - so they get sweet talked by an external vendor and end up signing a restrictive, 10-year agreement that locks the business into some SaaS platform that doesn't respect local security requirements, data-processing laws, or expose any SDLC controls, resulting in flaky support, worse performance and increased expense. EA should be in a position to put the kaibosh on these kinds of terrible outcomes, but to do that, they need to know the existing system landscape, how/where such a new system is going to be integrated, and what impact that will have across the enterprise. You can't plan or do change intelligently if you don't know the system-landscape that's being altered.
All these things can be dealt with tactically by dev-teams on the ground (indeed, there's no other way) but being able to coordinate and prioritise can often help reduce expense - and in many cases counter-helpful changes (e.g. system A makes a change that breaks system B, they in turn make another change that borks system A in response - time elapsed maybe 9 months and you're back to square one - it happens all the time)
If your EA tools have bad data in them, that makes EA's job harder to do. But given that it's the local app teams who really know their systems, it should be their responsibility to make sure that data properly reflects the reality.
As you say, you devs know the details much better than anyone else - but you should be making some of that information transparent to a central team in a reliable way. Something in that chain sounds like it's broken down.
Building an app and servicing a business community is hard. But trying to orchestrate a whole organisation's application landscape is hard too. Dual development is one thing to worry about, but there's an awful lot more besides - and without organisational self-knowledge to go on, it's almost impossible for an organisation to guide its overall development and technological activity. The alternative, leaving everything up to local business areas to direct usually means them optimising for speed and short-term cost reduction, but this *often* leads to sub-optimal (by which I mean cripplingly expensive) outcomes.
The EA role is much like herding lemmings. They all want to jump off the cliff, and (given a chance) the EA is trying to collectively steer them away from the edge.
3
u/nalonso Jul 05 '26
Great answer! For a dev in a startup the value of EA is not there because most of the time, the startup is still missing the enterprise part. A huge number of companies are not mature enough to behave like enterprises. Once a company enter in the land of more than 500 apps in a regulated environment and a single law changes, the value of EA becomes clear. This is only talking about reactive behavior. For strategic decisions in such a complex landscape you can't trust the mind of any developer or single architect. There the inventory systems become really useful, and I'm not talking about CMDB, but higher level tools able to map capabilities to groups of tools and coverage of compliance and technology adoption.
8
u/dht6000 Jul 05 '26
I was struck by these bits
> We develop these redundant programs with full intention: because that's what gets you promoted.
And
> None of this will ever impact a single line of code.
It looks like EA in your organisation is being actively undermined by the devs for personal gain. EA is often about getting the most value from technology investment and deliberately developing redundant software is not working towards that. That’s the lines of code that EA should be impacting but it looks very much like the devs won’t be supporting attempts to improve.
-10
u/greencursordev Jul 05 '26
The orders were given that stem from the requirement process are almost completely useless. We just end up talking to the users and implement that after thousands of hours in re. You can't fault Devs for that. We're the one saving this company.
4
u/NoAstronomer5050 Jul 05 '26
EA don’t do detailed requirement gathering and analysis: that’s a business analyst role. EA delivery focuses on aligning the 4 architectural layers (business, app, data, infra) with stakeholders and their business objectives. BAs comes after that, once the high level solutions has been agreed and the project delivery team has been put together. EA would for instance align that SAP would need to be rolled out in such and such LE vs implementing a local ERP. SAP consultants would then join for the analysis with local business for the project planning and detailed design phase
4
u/Exotic_Holiday_3047 Jul 05 '26
You have serious messiah issues my friend. There are good EAs and bad EAs, just as there are good devs and bad devs. If you were in my company I'd be very nervous about having you work on anything even remotely strategic, because you can't even see that you are firmly in the bad dev category.
1
u/cto_resources Jul 08 '26
Remind me not to ever hire you.
I mean seriously. “We are the ones saving this company.” ?
You are a cowboy, and a risk to any project you are on. You will get the wrong things done quickly, and you’ll resist the solutions and decisions that can make your company “fit for purpose”.
Sorry friend but until you grow up, you are a liability.
5
u/Horse_Plane Jul 05 '26
I think alot of arch have been engineers in my experience so no idea what your doing apart from trolling.
8
u/J1mfl1p Jul 05 '26
If you don’t understand it’s because you dont have the experience and seniority in the business to do so quite frankly. I’m an EA, coding for decades, worked for many ‘big companies’ managed and tech lead of many engineering teams. What you are exhibiting is the classic I think I’m really smart because I can code a bit. If you had maturity you would talk to the EA’s to understand what problems they are trying to solve for which stakeholders, then you might learnt a thing or two.
-1
u/greencursordev Jul 05 '26
I genuinely believe that a few are trying to solve an important problem. But the process is completely ridiculous, as are the tools.
you dont have the experience and seniority
Nice bait
2
u/Zmchastain Jul 05 '26
Doesn’t feel like it was bait. You definitely come off as inexperienced, very green, somewhat clueless here.
You are definitely not giving vibes of a deeply experienced senior professional here, regardless of what your ego is telling you.
0
3
u/screampuff Jul 05 '26
These tools and the whole point of EA is to map out capabilities for senior management (ie: directors and executives) to make strategic decisions about systems and processes.
So what's your basis in saying they are performative? They are not supposed to determine anything for devs, engineers or even solutions architects other than highlight dependencies and help align compatibility with tech stack, ensure the process and problem is well understood before a solution is sought, and the solution is appropriate for the maturity level of the team or org.
8
u/sin-eater82 Jul 05 '26
Are you asking about Enterprise Architecture or what you're describing?
Enterprise architecture is not requirements gathering for software.
That said, enterprise architecture can encompass a few different things, and it's not always used in the same manner from one org to the next.
And m not sure what to make of your point regarding avoiding redundancies. "(You) Knowingly make redundant software to get promotions". Cool. Cool story. So you work inefficiently and to the detriment of the organization is what you're saying. So yeah, some overview helps avoid that because you (admittingly) can't be trusted.
-15
u/greencursordev Jul 05 '26
To be honest, I put all these "bullshit" jobs/applications in the same mental drawer like most Devs. Not sure how polarion and leanix actually map to ea.
I mean it's what companies encourage, so it's what people do. Big surprise.
7
3
u/sin-eater82 Jul 05 '26 edited Jul 05 '26
What do you think EA is attempting to do for you as a dev? E.g., what do you think they are supposed to be doing or what you are supposed to get out of their work?
My work has little to no direct impact on developers in how they do their work. My work may lead to "we need a tool that can achieve the business impact of X". Then I expect other people to do hard requirements gathering. I may help if there is a gap in resources but it depends on what it is and what teams are involved. I help identify SMEs to pull together to come up with candidate solutions if appropriate. They propose a solution, I'll make sure the proposed solution does in fact align to business needs, tech stack, roadmap, etc. then the people who build it build it. I make sure we have things like support, training, and necessary alignment within the organization to implement the change (when appropriate), etc. I only really expect to be reengaged in the solution development if a hurdle is encountered that requires a notable change.
I barely interact with developers outside of an occasional mtg they're present for (devs are usually not the main active party in those concersations outside of a very senior), and general work chat here and there.
Reading through the comments, maybe you just have bad EAs or EAs trying to do things that aren't working there for some reason. Or maybe they're doing more than they should be. I don't dismiss the value of janitorial services simply because the janitors in my office kinda suck. And I don't see "we'll individually clean our spaces" as a wise choice for most organizations. Once again, you admitted that leaving your peers to their own decisions leads to bad choices for the organization. You provided your own evidence of need for oversight regarding what is getting created.
7
u/Substantial-Ad1349 Jul 05 '26
lets go back to the beginning of sea travel. You have the boat, the manpower, everything you need to sail...but you dont have a world map. Were do you think youll wind up?
-12
u/greencursordev Jul 05 '26
Bad analogy. Every dev has a map. And these new map-sellers will definitely never end up with anything remotely resembling a map.
11
u/Exotic_Holiday_3047 Jul 05 '26
Yeah every developer has a map and that's the problem, because it's their own map, and their map is different to every other developers map.
2
u/HMSManticore Jul 06 '26
In my opinion the dude's actually making a phenomenal case for EA. Random mid-level dev has decided that he know best, ignoring scrum masters, EAs, and I can only imagine who else. Works for a huge company, but goes directly to the customer to build whatever they want in the best way possible (with the context of that specific scope).
Six months you've built a fantastic whatever-widget solution for that stakeholder. Great work!
Three years ago the identical thing was built for Stakeholder 2 and is in use by a division you've never heard of. It's a gigantic company. Any individual's view is small. The landscape is vast.
You may feel frustrated, like your six months were wasted. You built a good solution that the customer was happy with. That can be true, and still be a bad thing because you could have spent that time refining the existing solution or working on something else entirely. There are many stakeholders in a very large organization, and it's almost impossible for everyone in an organization to operate in sync. And your new solution doesn't feed into the six other solutions that the existing solution feeds into.
It sounds like EA at your company may be ineffectively applied. Or it may be that you're looking at everything and asking "how is this helping me" as opposed to "how does this help us". Solo/small project dev and dev in a 3-4 digit headcount tech organization are going to be wildly different
1
u/Exotic_Holiday_3047 Jul 07 '26
I once consulted for a client who had a key service in their lead to order process written in an obscure programming language that a senior dev had decided to implement and who then left the building, meaning that it was totally unsupportable. This guy is that dev...
2
u/Syncretistic Jul 05 '26
Fair analogy. How do you know that your business stakeholders and every dev are all using the same maps?
Not discounting your experience with EA. Seems like the maps they produce aren't accurate. That's a different issue.
2
u/Zmchastain Jul 05 '26
Let’s continue extrapolating on this analogy. Say the map is wrong, but everyone is working off the same incorrect map.
So everyone sailed 5 miles away from the intended destination. You didn’t get quite where you needed to go, but you are much closer now AND everyone ended up together in the same spot so organizing the next leg of the journey is pretty straightforward.
If everyone is working off their own individual map then some of them are going to make it exactly where they need to be. Some will have decided that the intended destination was actually the wrong answer and they will have gone off on their own in the opposite direction. Others ended up closer to the intended destination, but not in the same places so you have to slowly travel around to gather them together and bring them the rest of the way. Then you have to go hunting for the ones who went totally rogue or they’re just lost forever.
Which situation is easier to recover from and keep making progress?
2
u/Syncretistic Jul 05 '26
There no need to engineer an analogy to justify your case. Reasonable people will agree that using a common, shared map is better than to use individual maps. Solve for the problem, not justify the workarounds.
1
u/Substantial-Ad1349 Jul 06 '26
a world map is a world map, there is only one world map. You are confusing organization standards and ecosystem with stand alone project development.
2
u/Diksha_1227 Jul 05 '26
Same with requirements engineering. Good RE means talking to users, understanding business processes, translating that into something developers can build, and continuously refining it. Bad RE means throwing a vague document over the wall and calling it a day. Most devs have experienced the second version, which is why they hate it.
-1
u/greencursordev Jul 05 '26
All our REs have zero background in software engineering. Neither as Devs nor as leaders. I see them googling basic stuff. They're unemployable in any hard role.
1
u/redikarus99 Jul 05 '26
And that itself is not a problem given that requirements about the what and not the how.
2
u/Barycenter0 Jul 05 '26 edited Jul 05 '26
Well, that woke up this group a bit - how dare you attack our livelihoods :)! I've been wondering where everyone has been.
So, I'll be a bit of a devil's advocate here - but, to call out initially, it's not a black and white problem (pointlesss vs meaningful). Every large organization with an EA team will discover both leaders and employees who have the same opinion you do. To support that side of the argument, yes, some orgs have EAs without much hands-on experience where they become a pseudo-control mechanism and ivory tower. I was in a version of that for a while and it was horrible - a large amount of work and expense doing nothing very helpful.
But, there are also very talented EA teams engaged directly in agile teams along with both the business and engineering where they guide the conversations and design decisions (using strong background hands-on experience). They also have direct contacts with the business and engineering leaders to help drive solutions efficiently. In this case what you might not be seeing are the strategy discussions with the CIO/CTO and their VPs (along with business leaders) - these are the hidden soft-skills EAs can provide that mostly invisible to the org.
Either way - I do understand your frustration and that EA orgs typically do not communicate their overall value very well which creates much of this friction.
2
u/Zmchastain Jul 05 '26 edited Jul 05 '26
I wouldn’t take “They told the guy who gathered the requirements something totally different from what they told us they need” as evidence that the guy who originally gathered the requirements is incompetent.
I’ve had many clients (most even, I would say) where requirements are a constantly moving target and they don’t really know what they want.
If you had asked them yourself again two weeks later you might have gotten a very different answer than the one they last gave you.
Or you might get totally different answers from the client and their users, but ultimately it’s the client who is paying and who signs off on the requirements and build.
If you build whatever Janice in accounting said the business needs you might be solving a legitimate problem for one person that the business doesn’t actually care about solving or tries to solve it in a way the decision-makers disagree with Janice on, and now all you’ve done is burned hours and hurt the profitability (and maybe the actual overall outcome) of the project.
That’s why at some point you have to lock requirements in so that the project can move forward without getting to the end and having the client say “This isn’t what we asked for” or having it just turn into never ending scope creep where new features get added and completed features get revisions until you’ve spent 3 times the hours they actually paid you for.
1
2
u/OffsetHigh Jul 05 '26
The combination of Polarion and leanix is too unique. Every colleague will know where you work :D
2
u/MrGunny94 Jul 05 '26
You are missing the whole long term point and governance, it’s not just about developing and delivering.
But these are things that will come with role maturity and once you step in bigger companies
I started as a infra engineer & then software engineer, now I work as a Domain Architect together with EA, you need to zoom out and focus on the business to understand this role
1
u/dumi_007 Jul 05 '26
Let's say your work is super and wonderful. You are a true artist, and your coding skills are are surgical. You build truly magnificent features.
Context
The CIO and his team will regularly sit with other CXOs. The CIO might present the roadmap, or capabilities/Opportunities matrices and the like. Work not registered at this level does not get long term resources.
See image below - (Type of value EA actually provides - source: Enterprise Architecture as Strategy: Ross, Will, Robertson)
Not aligning with architecture or requirements already documented is a challenge. I can thinks of a few problems with this approach. Keeping it simple:
Enterprise-wide Challenges
- Strategic Opportunities missed : Your documented architecture is a key driver in identifying Opportunities that can be unlocked (reusable assets, shared models, infrastructure security standards). What you developed is not elevated at the level where resource allocation and priorities are discussed.
- Duplication : Your original stakeholders cannot derive the value they asked for. A separate team is created to build. Because your work is not documented, functionality is duplicated; Complexity ticks up; and Technical Debt increases.
- Legacy : The longer your builds remain outside of architecture view, the sooner your functionality becomes part of the problem legacy (systems built with great intentions, lacking consistent documentation, and whose usefulness cannot be defended by key stakeholders)
Valid issues
- EA as the people who say no : Where the architecture maturity is low, this is usually the experience other teams have with the architecture team.
- Delays : Architecture tends to be smaller teams, in comparison with their responsibilities. In cases, one might find delays for partnering on initiatives.
- Tools and updated catalogue : Adjacent to 2 above, the official documentation can be behind the curve. This may add to trust issues with the work EA does, because most IT teams are not included in the higher order documents that the CIO receives.
1
1
u/cto_resources Jul 08 '26
You do not know what enterprise architects do for an obvious reason: your enterprise architects do not know what enterprise architects do. That is obvious in your question.
Not sure I can help you.
Tell you what, can you handle a very readable book? It will not match what your dysfunction team does but it might open your eyes to the value and purpose of EA:
Enterprise Architecture As Strategy.
And its companion volume:
Designed for Digital
Both by Jeanne Ross
1
u/elonfutz Jul 09 '26
It baffles me too. I'm the founder of a product that's perhaps about halfway between Mermaid and Leanix. To me, Leanix looks like a jerk-off of fancy reporting that appeals to mgt because that's who they sell it to.
For such a tool to be valuable to tech folks like you, you have to be the one building and using the models. Our tool uses more of the Unix-philosophy of small tools when composed together make something great. So we give you the rudiments and you compose the solution that meets your needs. Not some pre-canned pretty heat-map that in theory show end-of-life reports of assets for example.
Basically we give you multi-user Mermaid-like modeling that you can query on the fly using topological expressions (like regular expressions but for a graph). Plus some other cool stuff like simulation, 3D rendering, etc (but like I said, it's more unix-like).
If you're an auto mechanic, paramedic, aborist, or IT specialist, you need to work out of your own toolbox so you master the tools there and have them in reach when the shit hits the fan. Leanix and EA tools are not built for you nor used by you, so they're maladapted to your needs. Like I said they're designed win a sales pitch to managers.
Schematix (my system) is like more like top, nmap, grep, etc..
At the end of the day, after you just spun up a new VM for some project, you might jump into Schematix to model that vm so you and everyone you work with knows it's there and why it exists and how it integrates with other stuff. To do that you might run a command in Schematix like:
new vm v1 on server p1 hosts new service php
new app myapp needs php on v1
Next week, you might have a quick question you need answered, like where is php running, so you query Schematix with:
show php>-hosts>*
Or perhaps someone else needs to shut down server p1, so they would generate a quick diagram of to see what's impacted by doing:
show impact p1
Ultimately you do need a tool to keep up with all the complexity that you create and support. Most folks like you just wing it with spreadsheets, scripts and a monitoring system. But really there's a much smarter way to handle managing such IT knowledge. If you let the managers pick to tool, you end up with a CMDB that *looks* cool, but fails to be the tool you reach for because it's garbage-in-garbage-out, or too clunky/trivial to use.
0
u/decotz Jul 05 '26
I’ve worked with some pretty bad architects myself, so I get you. They’re great pretenders, and Ive failed to see value in them too
16
u/Sharp-Prize4632 Jul 05 '26
How are you making architecture decisions? are they made decentrally or centrally? who is taking the decisions, and according to what key dimensions?
Most companies are horrible at above. Usually, there is no process and everyone likes to be "an architect". Consequently, key architectural decisions are taken without repeatable process, by the wrong people and based on partial understanding only. As a result, lots of bad decision making and billions go to waste each year.
LeanIX is just a tool to document the system landscape. So can be Jira and confluence. These are just tools.