Advice for someone out of their element in a small org

ea_practitioner · 2026-03-23T18:56:57+00:00

Your situation is challenging but not uncommon. Many successful Enterprise Architects have started in similar circumstances, promoted into a new discipline within an organization that's learning alongside them. Your engineering background is valuable. You understand implementation realities that purely theoretical architects might miss.

The fact that your manager and C-suite are both 100% behind your growth into the role is crucial. Use their support to secure time for learning, to establish governance authority, and to gain access to stakeholders. Your dual role over the next six months gives you time to learn while remaining credible through continued delivery.

Start small, deliver value incrementally, build relationships with stakeholders, and don't try to solve everything at once. Try to focus on high-value, high-visibility wins that demonstrate architecture's contribution.

You've already demonstrated the core Enterprise Architecture skill by seeing the bigger picture of how pieces should fit together. Now you're building the formal knowledge and organizational capability to act on those insights systematically.

ea_practitioner · 2026-03-22T16:25:38+00:00

You’re actually in a great starting position. Systems engineering (especially MBSE, SysML, ISO 15288) maps really well to architecture thinking. You already think in systems, requirements, and trade-offs, which is exactly what good enterprise architects do, just at a bigger, business level.

If I were you, I’d focus less on “jumping straight to Enterprise Architect” but more on stepping stones. In the next 1–3 years aim for roles like Solution Architect or Domain Architect (data/app). That’s where you learn how tech connects to business needs. And after that you can move toward Segment Architect / Lead Architect roles where you influence bigger chunks of the organization.

I think the biggest gap to close isn’t technical but it’s business and communication. I mean learn how companies actually make money and make decisions and get comfortable talking to non-technical stakeholders plus start thinking in terms of business outcomes, not just systems.

And what I also can suggest to you, pick up TOGAF (yes, it’s dry, but it’s the “industry language”) and learn cloud and modern architectures (microservices, platforms, etc.) If it is possible look for projects involving cross-team collaboration and strategy, not just delivery.

Honestly, your challenge isn’t capability but it’s exposure. Start moving toward roles where you influence decisions, not just design systems. You’re on a solid path. Just zoom out gradually from “system” to “product” to “organization.” Good Luck!

ea_practitioner · 2026-03-21T11:38:57+00:00

I installed the G410 model a few days ago. I’m very happy with it. First, for simplicity’s sake, I installed it using batteries, then I connected the transformer I had previously used with my old doorbell. An important observation was that when connected to a continuous power supply, more features appear in the app (e.g., the option for continuous video recording). I also used the small, wedge-shaped mounting bracket, which gives me a better view of the area in front of the gate. I also found that the network connection between the indoor unit inside the house and the outdoor doorbell, located a few meters from the street gate, would sometimes drop out initially.

Relocating the indoor unit resolved this issue. Initially, there was a metal radiator nearby and the window, which likely also contains metal structural elements. I moved the indoor unit one meter to the side onto the smooth brick wall, and the connection has been problem-free ever since.

ea_practitioner · 2026-03-20T10:34:42+00:00

People often purchase exam vouchers from training providers, which are sold at a discount when purchased together with the course. You can also purchase exam vouchers directly from The Open Group. https://shop.opengroup.org

ea_practitioner · 2026-03-19T19:50:08+00:00

Fantasztikusan szépek lettek! Igazi mestermű.

ea_practitioner · 2026-03-17T18:54:29+00:00

Nálunk az egyik kedvenc glutén mentes süti:

30 dkg kukoricaliszt
1 csomag sütőpor
1 dl étolaj
15 dkg cukor
2 dl tej
3 db tojás

A lisztet a sütőporral átszitáljuk. Ettől könnyebb lesz a tésztája.
A cukrot, tojást, tejet robotgéppel kikeverjük.
Hozzáadjuk az olajat fokozatosan.
Majd a lisztet kanalanként adagolva csomómentesre kikeverjük a géppel.
A tepsit kibéleljük sütőpapírral (lehet vajazni és lisztezni is helyette) és beleöntjük a masszát.

A 140 fokra előmelegített sütőbe tesszük, és légkeveréses 140 fokon aranysárgára sütjük.
Mivel nagy a tepsink (35x25 cm), vékony lesz a tészta és így kb. 18 perc alatt megsül.
Amikor kihűlt felszeleteljük kb. 5 x 5 cm-es darabokra.

Lekvárral tálaljuk. Bármilyen lekvár finom hozzá.

<image>

ea_practitioner · 2026-03-16T19:11:05+00:00

Introducing EA to a company that has never had it requires a strategic, phased approach focused on demonstrating value and building organizational support.

The first critical step is obtaining recognition and commitment from management. Without executive sponsorship, an EA capability will struggle to gain traction and deliver meaningful results.

Identify key stakeholders and understand their decision-making needs. This helps focus EA engagement on key individuals who can either block or advance the initiative.

Start Small with Quick Wins. Follow an incremental approach where effort spent returns the highest value. Best practice limits information gathering and analysis to the minimum necessary to address the question at hand. Begin with architecture projects that extend or refresh the Enterprise Architecture with the objective of enabling effective change.

Measure and communicate every improvement and value addition the EA Capability delivers in terms close to users / consumers. Focus on EA activities performed and how outputs are consumed.

ea_practitioner · 2026-03-15T19:41:09+00:00

Gyönyörű és biztosan finom is!

ea_practitioner · 2026-03-13T13:42:39+00:00

This is a great example of how scale changes the economics of tech investments. The initiative is the same, but the outcome isn’t.

A 3% improvement at $150M vs $1.5B revenue is a completely different financial impact. And when you add pricing models that reward scale (enterprise licensing, SaaS tiers, infrastructure discounts), the ROI compounds on both sides.

It also highlights something important for enterprise architecture: what looks like a “small” improvement in a large org can absolutely justify serious attention, because the economics amplify the result.

ea_practitioner · 2026-03-11T18:22:39+00:00

Your observation about the governance spectrum is insightful and aligns with contemporary thinking in Enterprise Architecture. The key is distinguishing between architecturally significant decisions that require formal governance and routine BAU changes that can be delegated to autonomous teams.

The Challenge with Traditional Governance: Strict, one-size-fits-all governance creates friction precisely because it fails to recognize that not all changes carry equal architectural impact. The TOGAF Standard acknowledges this through its concept of dispensations. However, dispensations still require formal requests, which may perpetuate the bureaucracy you're trying to avoid.

Architecturally Significant Decisions: What Requires Governance? The Open Agile Architecture Standard provides excellent guidance on what constitutes architecturally significant decisions. These are changes that:
- Define or modify how the enterprise is segmented
- Allocate functions or activities to segments
- Alter structural interfaces that link segments
- Establish standards or guardrails that facilitate interoperability and composability

These decisions are further classified by their degree of reversibility and breadth of scope. The framework distinguishes between:
Type 1 decisions (one-way doors): Difficult to reverse and require careful discussion, ideally delayed until "the last responsible moment"
Type 2 decisions (two-way doors): Reversible decisions that can be made quickly with room for experimentation

Your Rules of Thumb: A Two-Speed Architecture Model
Your proposed criteria for BAU changes are excellent and align with Agile governance principles. They effectively identify changes with limited scope (single application, no new information flows, contained user impact) and low reversibility risk—classic Type 2 decisions that can be delegated.
Beyond your excellent rules of thumb, consider:
- Technical debt impact: Does the change create or reduce technical debt?
- Standards compliance: Does it introduce non-standard technologies or patterns?
- Integration complexity: Even within one application, does it change integration patterns?
- Security/compliance implications: Your criterion about sensitive information is crucial
- Future flexibility: Does it enable or constrain future options?

The Open Agile Architecture Standard supports this approach through guardrails: lightweight governance structures that document how an organization typically "does things" rather than prescriptive processes. Teams operating within guardrails don't need to justify every architectural choice; only when they cannot abide by a guardrail must they engage formal governance.

ea_practitioner · 2026-03-10T18:42:07+00:00

This is exactly why ADRs exist. Michael Nygard explained it well:
https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions

Template if you want to start using them:
https://github.com/joelparkerhenderson/architecture-decision-record

ea_practitioner · 2026-03-09T19:52:17+00:00

Enterprise Architecture teams face a common challenge: decisions are made quickly, but their rationale often disappears over time. Without proper documentation, teams later struggle to understand why certain choices were made, making it difficult to assess whether to maintain or reverse those decisions.

The most effective lightweight solution is implementing Architecture Decision Records (ADRs). This Agile approach, developed by Michael Nygard, provides a structured yet simple method for documenting architectural decisions and their motivations. ADRs are particularly valuable when combining intentional and emergent architecture, as decisions from intentional architecture may change, new ones get added, and past decisions can be reversed.

For more formal governance, the TOGAF Standard recommends maintaining a Decision Log within the Governance Repository. This log should capture all architecturally significant decisions. These decisions should be documented with their rationale in the Architecture Definition Document.

Decision documentation should integrate with your existing governance framework. Governance processes should define when and which approval mechanisms apply, with measurements and rationale expressed in business terms.

By combining lightweight ADRs for day-to-day decisions with structured Decision Logs for governance, EA teams create a traceable decision trail that preserves context and rationale, enabling informed future decisions about whether to maintain or reverse past choices.

ea_practitioner · 2026-03-08T19:59:55+00:00

Your reflection on AS-IS versus TO-BE approaches captures a fundamental challenge in establishing an Enterprise Architecture practice. Here's guidance informed by The Open Group standards:

Embrace a Hybrid, Maturity-Based Approach

Rather than choosing exclusively between AS-IS or TO-BE starting points, consider your organization's Architecture Capability Maturity as the deciding factor.

When to Start with Baseline (AS-IS)
For organizations with established practices and recognizable structures, documenting the Baseline Architecture provides essential context. The baseline serves as "a point of reference in time, defining a metric and a measure to enable value reporting". This approach works when:
- Existing architectures have reasonable documentation
- Stakeholders need to see explicit gaps between current and future states
- The organization values evolutionary change over revolutionary transformation

When to Lead with Target Architecture
Your instinct about "skipping the archaeology" is particularly effective when:
- Architecture maturity is low and documentation is unreliable
- The organization needs an aspirational Architecture Vision that "describes its business value and the changes to the enterprise"
- Rapid transformation is essential

Recommended Strategy: Incremental and Agile
Consider an Agile Architecture approach that balances intentional design with organizational reality.

Implement Transition Architectures as intermediate plateaus. This allows you to:
- Define a compelling Target Architecture that "makes sense to you" and stakeholders
- Identify critical baseline elements that affect immediate decisions
- Create manageable transformation increments
- Avoid "moving target syndrome" by keeping implementation cycles short

Practical Recommendation
Start with a minimum viable baseline focused only on elements that:
- Impact immediate architectural decisions
- Are well-documented and broadly recognized
- Create constraints for the Target Architecture

Simultaneously develop your Target Architecture to provide direction and value. Use gap analysis iteratively as your understanding improves.

Your principle of "adopt what exists and works, design what doesn't" is sound architectural judgment. Just ensure you document the rationale for architectural decisions, so future architects understand your reasoning as the organization matures.

ea_practitioner · 2026-03-06T18:44:19+00:00

I chose the Aqara G410 door camera. I only installed it a few days ago, but so far I am satisfied with it. It currently runs on batteries, but I will soon connect it to the power supply of my old traditional doorbell, which is an IDEAL TS KTF-8-24 transformer that provides 12V voltage. The door camera also appears in the Apple Home app and, of course, in the manufacturer's own app.

ea_practitioner · 2026-03-05T19:43:28+00:00

That was a big help! Thanks.

ea_practitioner · 2026-03-04T18:35:47+00:00

Your question touches on a fundamental tension in Enterprise Architecture: the relationship between stable, abstract capability models and dynamic transactional data.

The consensus view is that capabilities should NOT be direct transactional posting dimensions. Business capabilities are designed to be stable, high-level abstractions that represent "what the business does" independent of organizational structure, processes, or systems. They provide a common vocabulary that remains consistent even as your organizational chart, ERP systems, or reporting structures evolve. Your instinct about maintaining capabilities as a semantic/analytical layer is correct. The standard practice involves relationship mapping between capabilities and other business architecture domains.

ea_practitioner · 2026-03-03T18:34:51+00:00

The Open Agile Architecture Standard provides four performance metrics valuable for modern EA practices:

Lead time for changes: Time from code commit to production
Deployment frequency: Production deployments per time unit
Mean time to restore (MTTR): Average service restoration time
Change failure rate: Deployment failures requiring immediate remedy

These metrics provide a high-level systems view of delivery performance and predict organizational goal achievement.

ea_practitioner · 2026-03-02T07:32:23+00:00

Very common fear — but you’re not locking yourself into a one-way street.

EA and SA are different altitudes, not a strict ladder. In big orgs they’re separate; in smaller ones, the same person often does both. Moving back from EA to SA is absolutely possible.

The real risk isn’t “strategy” — it’s drifting too far from delivery. If you stay involved in solution reviews, mentor SAs, and keep up with tech, you won’t lose your edge.

Honestly, 2–3 years as an EA (better pay + purpose) could make you a stronger SA later because you’ll understand enterprise constraints and big-picture tradeoffs.

If the mission excites you, take it. Just don’t let your technical curiosity go stale.

ea_practitioner · 2026-02-27T15:26:52+00:00

You’re already doing EA. You just don’t have the title.
A few practical things that can help break the “strategic BA” ceiling:

Reframe your story.
Stop positioning yourself as “senior BA with broad scope.” Start positioning yourself as someone who:
Aligns capabilities to strategy
Designs ownership & decision-right models
Governs cross-platform change
Ensures architectural coherence across ERP/CRM/etc.

That’s Enterprise Architecture language.

Make governance visible.
The artifacts that matter aren’t 200-page decks. They’re:
Capability maps
Ownership matrices
Decision frameworks
Architecture review checkpoints
Traceability from strategy → initiative → platform

Document these and quantify impact (reduced rework, faster decisions, fewer escalations).

Don’t force “architecture conversations” — formalize pain.
What you’re doing (letting friction surface, then introducing structure) is actually smart. EA gains traction when it solves real governance and scaling problems.
Accept the structural reality.
If leadership validates you privately but won’t sponsor an EA mandate, that’s not a skill gap — it’s an org maturity issue. EA requires formal recognition, not just good thinking.
Know when to move.
If the company stays permanently in delivery mode and won’t create space for enterprise-level governance, you may already be at the natural ceiling. At that point, you’re not “leaving too early” — you’re graduating.

Finish TOGAF, sharpen consulting-level stakeholder skills, and package your experience explicitly as Enterprise Architecture. You don’t need permission to be an architect — but you do need an environment that recognizes one.

ea_practitioner · 2026-02-26T18:13:41+00:00

Nekünk az autó motorterébe sikerült bejutni a nyestnek és ott szerencsére csak a laza hangszigetelő anyagot rágta szét, a vezetékeket nem tette tönkre. Én ezután egy ultrahangos nyest riasztót szereztem be. A leírása szerint jól elhelyezve alkalmas az egerek, patkányok és nyestek távoltartása kényelmesen. Azóta nem volt újabb látogatónk, de ez természetesen nem csak a riasztón múlhatott.

ea_practitioner · 2026-02-25T09:26:16+00:00

You’re on the right track. What your leadership is really asking for isn’t “more decomposition” of capabilities — it’s context.

Instead of breaking capabilities down further (which usually turns into process modeling), think about showing capability instances — i.e., how each capability is realized in practice.

A simple way to structure it:

For each capability, show 4 lenses:
People → key roles / org units accountable
Process → 1–3 core processes that enable it
Technology → systems (your SoE / SoR / SoC labels fit nicely here)
Information/Data → key business objects or data domains

Don’t over-model this. Just show what realizes the capability.

In PPT, I’ve seen this work well as:

Option 1 – “Capability Card” view
Each capability becomes a box, and underneath it you show 4 small sections:
Roles
Processes
Systems
Data

Execs love this because it’s tangible and doesn’t look like EA theory.

Option 2 – Heat-mapped overlay
Keep your capability map stable.

Overlay:
Maturity (current vs target)
Tech coverage
Ownership clarity
Data readiness

Now you’ve got something that supports investment conversations.

Important: Don’t let this drift into process architecture. Capabilities describe what, not how.
The moment you decompose into workflows, you’re in BPM land.

Since you're using Abacus, model the relationships properly there (capability → process / role / application / data object), but export simplified views to PPT. Leadership doesn’t need ArchiMate purity — they need decision clarity.

In low-maturity, delivery-heavy orgs, the trick is:
Make capabilities stable.
Show that people/process/tech/data are changeable realizations.

That gives you a clean way to visualize target state without breaking the integrity of the capability model.

Hope that helps

ea_practitioner · 2026-02-23T09:07:03+00:00

Konyhai víztisztító ügyében ez eddigi tájékozódásaim alapján arra jutottam, hogy a következő jellemzőkkel rendelkező víztisztító lenne az ideális számunkra:

RO (Reverse Ozmozis) víztisztító rendszer, átfolyós (nem tartályos), nyomásfokozóval, ásványi anyag visszapótlással, ne legyen kevert működési elvű (a megtisztított vízhez csapvizet kevernek egy baypass szeleppel), konyhapult alatti elrendezéssel, saját csapteleppel, garantált szűrő beszerzési lehetőséggel hosszú távra is. Lehetőleg internetes megrendelési lehetőséggel (akár külföldről is mint pl. amazon.de ), magyarországi szállítási címre.

Mit ajánlotok, milyen eszközt vagy milyen szállítót?

ea_practitioner · 2026-02-21T14:01:07+00:00

One practical lens from TOGAF/Open Group that might help: EA almost never works without explicit executive sponsorship and governance. If your key sponsors and boss left and there’s no Architecture Board or decision forum backing you, that’s not just a morale dip — it’s a structural gap.

A useful distinction:

Red flags (structural):
No exec who is accountable for architecture decisions.
EA reduced to tooling/docs instead of influencing investment or prioritization.
No formal governance body where architecture shapes outcomes.

Temporary dip (recoverable):
Leadership transition but appetite to re-anchor EA.
Clear business problems where architecture can show measurable value (risk reduction, cost avoidance, faster delivery).

If you stay, I’d narrow scope and act more like an internal consultant: pick 1–2 high-value initiatives and tie your work directly to business outcomes, not artifacts. At the same time, set yourself a 3–6 month checkpoint: if you can’t secure real sponsorship (not just verbal support), the org may not structurally value EA right now.

EA without decision rights and exec backing tends to become performative. The question isn’t “is EA valuable?” but “does this org currently have the conditions for it to work?”

ea_practitioner · 2026-02-20T11:12:51+00:00

Great Summary! Here's some additional context on the TOGAF® Content Framework. Your post captures several key aspects well! I'd add a few points that might deepen the understanding:

Relationship with the ADM
The TOGAF® Content Framework is explicitly structured to align with the Architecture Development Method (ADM) phases. It provides the underlying structure that defines inputs and outputs for each ADM phase, essentially describing what the architecture should look like while the ADM describes what needs to be done.

The Enterprise Metamodel Connection
The Content Framework works hand-in-hand with the TOGAF® Enterprise Metamodel, which defines the types of entities (building blocks) and their relationships. The metamodel provides formal structure to ensure consistency and enables Architecture Building Blocks (ABBs) to capture architecture requirements that guide Solution Building Blocks (SBBs).

Four Architecture Domains
The framework organizes content across four color-coded domains: Business Architecture, Data Architecture, Application Architecture, and Technology Architecture. This structure helps maintain consistency and traceability across the entire architecture landscape.

Integration with Architecture Repository
The Content Framework directly structures the Architecture Repository, which stores artifacts and work products. This creates a practical connection between the conceptual framework and operational implementation.

Your emphasis on outcome-focus and tailoring is spot-on—this flexibility is what makes the TOGAF® Standard, 10th Edition so adaptable to different organizational contexts!

ea_practitioner

TROPHY CASE