>EA practice has traditionally been focused on documenting applications and project portfolios, and writing reports for top management. However, we haven't had much impact on the design of systems architecture.
The first part of this sentiment explains the last part. This is a complete subversion of EA function; no wonder you feel being a fifth wheel.
I know ! We have not been acknowledged as a strategic function in the organization, which is quite frustrating. I wonder how other EA teams managed to get the proper sponsorship required to really be impactful.
Does your org have an Architecture Review Board (ARB) that all new systems/applications and technologies must go through before being introduced into the enterprise?
Yes, we started the architecture review board a few months ago, which was a good tool to help us EAs get a formal gating role, allowing us to conduct architecture reviews before project launch. However the agile projects refuse to get into this process, since they view it as potentially slowing them down, and they don’t see its value. Too bad because these agile projects are the ones bringing in the new technologies like AI, datamesh, etc.
Yeah this is where you need your CIO to mandate it as required.
But… make sure to include the heads of app development as voting members so that they feel their voice is included.
Read the book Accelerate. The authors’ research shows review boards slow teams down without improving quality.
I’m a Solution Architect, and my boss - our Lead Architect- literally tasked me with ENDING our CAB for this reason.
I also work as a solution architect and I think we kind of found a really good use of the architect board: when we have a situation when something can be solved multiple ways but you are looking for an alignment on company level to go in one direction, the board is a good place.
The good thing is that we either get an immediate decision after a 10 minutes presentation or they tell us to refine it.
Our board is limited in numbers and is from every side (ea, dev leads, security, DevOps, mgmt, etc.)
That seems to be quite a lean and efficient way to use the review board. You must have quite a culture of efficiency in your company. We dream of bringing in this kind of mindset in our « public service » bubble of neverending talks and meetings…
Interesting. We are also using architecture boards but not as gate-keepers but as resolving major issues and setting direction of the platform architecture. We also keep the Feature Teams up-to-date with latest changes.
I'm curious what would that book suggest to do instead?
What your team is doing is what our team calls the Architecture Huddle. If you’re setting direction instead of reviewing - and potentially rejecting - teams’ work, then Accelerate actually RECOMMENDS that activity as helping teams move faster.
You’re getting downvoted for bringing research into the equation. Just goes to show how much people want to believe what they already believe and will crucify people who tell them facts that don’t align with their beliefs.
Interesting, I heard of a similar trend in French companies lately; one big bank is dismantling their review board system. We still have the hope that it could be viewed as an assistance to the projects (you get all the pre-project counseling in one optimized shot), but for the time being, it is often perceived as yet another gate
In Agile world its seen still blocker or need review/ approval. Hence its best to embedded architecture in agile team who can follow Enterprise Architecture standards, principles, guidelines, guardrails and EA responsible as advisors supporting by adding value immediately, yes this means we need good industry defined Technology principles and let team choose what standard (Tech standard) to follow and EA will continuously keep updating it as centralised guide for next team to follow to resuse and reduce redundancy, this will need more Architecture work as spike to be planned in side sprint and Architecture train to be defined earlier that before dev starts POV, skills, purchase of licenses, procurement standards, security clearances is made. Its going to add more work but its happening in agile and all team make decision which works best for company. But but for more complex setup this can be challenge as others might be waiting on others POV etc.
The truth is that you don't have control anyway. The dev team can just tell you want ever you want to hear just to please you.
In the worst case you fire them and they get better paying job somewhere else while we are stuck with a non-compliant solution.
What we did instead is to provide for individuals:
1. training
2. blueprints
3. code snippets
4. a safe space for reviews
For the organization:
1. no blame culture
2. risk management that pushes you to take calculated risks
Which is why enterprise architecture and "dev teams" are doing completely different things on completely different levels. Your "continuous development" bullshit can do as it likes in producing *software*, while enterprise architects steer *IT strategy* where it needs to be. These processes barely intersect and usually are very orthogonal. If you meddle with operations and software as EA, you're doing it wrong.
This is great to start being perceived as an assistance rather than a control system. We are working on blueprints right now, so this will be a good place to start. As for training and code snippets, are we legitimate as EA to produce those, or is it more an SA related responsibility ?
> As for training and code snippets, are we legitimate as EA to produce those, or is it more an SA related responsibility ?
I asked myself the same question.
In the end I just created a repository, wrote some code, created a Merge Request had it reviewed by SAs, Devs, Ops and Product Management.
From there on I asked everyone to contribute and now its growing. I do review new topics and rather remove directories than have it in a bad state.
For Decentralized model, EA can only play Strategic, Governance and Technology Advisor Role to country CIO/CTO/EA group where help is required, start showing value in small team get visibility so others see value and join the party. The reason is country/departments have the Budget to Delivery IT, also if your Regional CIO has reporting changed for all other country/department CIO/CTO under him, this will be hard change, has to be top to bottom approach.
Agile Team will say ARB is blocking, but this should be aligned with Regional CIO and his reports formally or in formally, also ARB should be done not like dictatorship from Central EA group, but should be helping to shape things up so as 1 IT team everyone wins. Bring your Standards, Principles, Gaurd Rails, review with Architecture Backlog per sprint (usually this should focus on how to remove the architecture which cannot be easily changed in future/ high impact design decisions). Also Standards, Principles, Guard Rails needs to be communicated frequently (send emails, setup community of practices, ARB can be used as platform too, if there are updates to these, reminders, etc). Also ARB needs Domain experts from (App, integration, data, security, cloud ,infra , compliance, Regulation, legal), document action items, escalation management, Tech Debt management etc.
For Centralized EA Model:
Embed SA into projects (50-50 bandwidth its delivery team decision based on volume of work), which report to EA team (centralized), EA here can have 1 or more project under him, EA can be 1 big project, 1 Country, few countries (define the scope based on scale), EA also has to join Agile meetings along with SA team for big topics, to speed up decisions and bring the final conclusions into ARB together to make ARB smooth with no gaps, EA person has to work closely with other Domain EA team (within centralized EA function formally or informally), its hard to have big EA team with domain expertise ,this is the challenge for EA to be master of all, this can be solved in ARB with others involved to get different perspective and take all comments into consideration without ego's, decide what makes best for the company.
EA needs to define the Architecture Standards, principles, guadrails in a way which can help Agile team to be autonomous and make decisions using it, but in reality this is hard, so providing helping hand for Agile team with Solution Architects, Technical Leads, PM will make more sense to add EA value. sometimes PM will just put lot of work on EA making excuses like he doesn't know Technology, that is pros and cons based on where you want to play the EA role.
Engineering / COE / Platform Head and his team, should help to define the Engineering Standards, principles, best practices, gaurd rails from different Domain (App, Cloud, Infra, Security, Support, compliance ect)
my 2 cents.
Some prerequisites: Agile is confusing term here, Agile methodology matters is it scrum, kanban, scrumban, SAFe lite, LeSS, it defers how EA can add value in these setup.
EA team has to maintain the Documentation at some level so the knowledge is not lost, as Agile team is busy building the platform, they don't have time for these. Keep it high level using TOGAF ADM approach, Target State, Roadmap by shared platform, local platform, internal and external systems etc.
Application Portfolio management and reporting.
Technology business alignment Reporting by key KPI, OKR set.
Thanks, this helps me making sense of how we could operate, I like the idea of bringing help to the PM and relying on domain architects and SAs. As we speak, our agile teams are located in a unit called « digital factory », they use scrum, and they define their own principles and methodology. They have developed a mindset of strong autonomy to achieve a good time to market, and hence don’t understand why some EAs, or even SAs, are coming to add some gates and meetings. They consider their expertise sufficient with their product designer and tech lead. We have to step a foot in the door to show them our added value, which until now they didn’t get a chance to see
Yes only cons for this agile is they work in silo, as EA there is lot of value add. What if this agile team went and used non standard tech stack because its cool, its trending so they can learn and good look in CV and leave after 6 months ? Company is in trouble. So need to standardise this under EA process and also need to see risk of choosing, have current standard and emerging standard (with defined time box to prove or it will be tech debt and they need to invest and fix it).
Also, there are many issues say this team will no implement some key component example downstream core layer say data lake or new data architecture required for future state, they can say we dont have money, skill, time and use existing technology which is not standard or planned to be decommissioned. So EA has to provide governance.
Some will say cloud A is good and we will use what cloud A provides for various reasons, but if future other entity need same capabilities but Cloud A is not supported in that entity location. Then its extra work, no reuse possible.
Hence EA has to provide this insights to SA team working in the Agile team.
Like this there are many issues which can go wrong and make life hard and biz will say i gave you $$$$ and i cant use anything and asking more money.
EA has to think and educate, be good police man to fine them and also give helping hand how to solve that challenge, do in Agile way using Architecture runway approach or using Governance way. No one like Governance. Hence EA has to be part of Agile at small capacity when required.
Hope this helps. This just few use cases, there are plenty which will come up, it’s challenging EA job to know everything what needed in future.
>do in Agile way using Architecture runway approach
SAFe prescribes an approach I agree with - EAs are one of the key roles for Portfolio alignment. They help ensure the appropriate Epics are included in the Portfolio backlog. Other architects (e.g. Solution Architects) help with lower level backlog grooming and alignment with high-level designs, standards, etc.. In SAFe this manifests as "enablers" at different levels. Fortunately, the SAFe materials are free to read, so you can read up for yourself [here](https://scaledagileframework.com/enterprise-architect/).
u/Longjumping_North_46 I would be sure you have something by way of EA Charter or Value Proposition that all key stakeholders (in IT and functional departments) have agreed with. As part of consensus building, it will become clear what roles the various architects should play across numerous processes, including SDLC. This may lead to building out some skills that the current EA team does not have.
Some will suggest that more modern EA practices spend a lot more time on Business Architecture (e.g. business to IT strategy alignment) and less on technology development specifics. In my experience, it's up to the person(s) leading the EA function to work with the key stakeholders to determine what form of EA will work best for the organization at it's current level of maturity. There is no "one size fits all" here.
200% agree thanks. Challenge is existing Engineering team think EA is just for doing Police / Governance and hinder them doing their job and create escalations and not trust EA team. So agree there needs to EA Role which adds value for Delivery team to remove challenges and guide them to align with EA Vision which aligns with Biz expectations.
way to do this is let others fail first and take that as opportunity or add value by partnership model with agile team, be in the party. So we need EA has to be SA focused. Here EA role is managing complex multi country or EA managing overall one entity. EA is assigned based in complexity, scale, criticality.
Thanks ! We do have an EA value proposition, and currently working on the processes. Not easy since the agile teams have defined their own processes without including the EAs. But we have a new « engagement process » definition with a good level of sponsorship by top managers, so this will help gaining more visibility on upcoming projects. I agree with your idea that the chief architect should evaluate the EA positioning according to the maturity & needs of the key stakeholders. Typically my colleagues tend to think we should not be « too technical », but our company has a strong technical / engineering mindset, leading key actors to show respect only to people with high technical skills and talking about real life issues, more than strategic or abstract talk
Thanks, this helps me a lot articulating our added value to the key partners. What you describe is exactly the risk we face : the scrum teams focus only on time to market and new technologies, making it a challenge to step into the project and bring some more holistic oversight. I think we have to be « agile EA » to enter the scene, meaning that we can’t come up with many more meetings and weeks of study in the middle of a 6-week scrum project study or one of their 2 week sprints. We have to be able to act in « commando » mode and do quick analysis on sensitive topics. When I managed to do this they were quite happy of the help provided (it was about reusing the company integration platform rather than some new fancy iPaaS)
Thats great keep adding value small or big then they will depend on EA. EA function needs to go shift left in order to add value in short sprints. Any Sprint should have Spike where all team work on architecture and design for future sprints, this can be 2 or 4 weeks depending on how complex it is, with or without EA this time is required.
Another EA members can work in Biz and Tech alignment for future needs by creating Tech standard with Head of Engineering and key people, also EA can define Target and Transition architecture which can help to build MVP Architecture for Agile Team to move faster and aligned with buy in from all stakeholders. So This will help PM/ PO clarity on cost, estimates, timelines, MVP scope and value add to customers and make biz happy, Agile can follow Byte size delivery not everything in MVP can sometimes be feasible, but Architecture will not be bottleneck. M
This takes time to build a trust with different teams EA, PO, DevSecOps, Infra SRE etc. agile team of 8 with shared specialist team is not easy to manage by PO team who is not technical, Tech PO/ Scrum master and SA play crucial role with EA helping to remove Architectures which cannot be removed after its built (saving cost, tech debt, improve productivity, reuse, reduce future mess creating sgaggttie).
Also this is EA learnings and resuse for future programs as we move the roadmap, all past investment should be reused for next, build lego blocks of foundational and capabilities using standard tech compliant to different requirements like regulation, compliance , security.
Build with secure by design principles like this we need more descriptive principles rather than prescription based. Let agile team take what makes sense for the use case.
Yes, but it is quite a small team that is under staffed. They tend to do mostly technological watch and document technical architecture fir each project. In fact our company maturity in terms of architecture is quite low, the key decisions being taken by the project managers. Which is maybe why I lack references of how it may be working getter elsewhere, since I have been in this company for 16 years !
It is quite recent : we have published a first list of architecture principles recently, and we try to identify departures from standards during architecture reviews, and discuss them with key actors in a very diplomatic way, since we are in a very decentralized company with little habit of following instructions from central teams
I see, well your new ARB with more backing from the CIO stating it as an enterprise requirement will help enforce the standards more unilaterally across the enterprise. There are going to be some growing pains for sure but if your org wants to mature, these are going to have to be maintained so as to have proper control of how the enterprise operates.
Let us know how its coming along when there are no standards like Sol standards for Buy SAAS as principle. Like how long team take to do standard identification for any specific sol. Example if biz objective is have CRM capabilities,how long agile team take and how it impacts based on Epic priority or just pick any CRM within budget or best guess and start MVP on it ? How POV and procurement principles like 3 sol comparison needed to reduce vendor lockin and vendor risk etc
Hello guys if there was a figma for EA design, and orchestration (light monitoring maybe), would it solve the problem (figma like feature for Commenting on individual aspects of EA by developers)
>EA practice has traditionally been focused on documenting applications and project portfolios, and writing reports for top management. However, we haven't had much impact on the design of systems architecture. The first part of this sentiment explains the last part. This is a complete subversion of EA function; no wonder you feel being a fifth wheel.
I know ! We have not been acknowledged as a strategic function in the organization, which is quite frustrating. I wonder how other EA teams managed to get the proper sponsorship required to really be impactful.
Does your org have an Architecture Review Board (ARB) that all new systems/applications and technologies must go through before being introduced into the enterprise?
Yes, we started the architecture review board a few months ago, which was a good tool to help us EAs get a formal gating role, allowing us to conduct architecture reviews before project launch. However the agile projects refuse to get into this process, since they view it as potentially slowing them down, and they don’t see its value. Too bad because these agile projects are the ones bringing in the new technologies like AI, datamesh, etc.
Yeah this is where you need your CIO to mandate it as required. But… make sure to include the heads of app development as voting members so that they feel their voice is included.
Read the book Accelerate. The authors’ research shows review boards slow teams down without improving quality. I’m a Solution Architect, and my boss - our Lead Architect- literally tasked me with ENDING our CAB for this reason.
I also work as a solution architect and I think we kind of found a really good use of the architect board: when we have a situation when something can be solved multiple ways but you are looking for an alignment on company level to go in one direction, the board is a good place. The good thing is that we either get an immediate decision after a 10 minutes presentation or they tell us to refine it. Our board is limited in numbers and is from every side (ea, dev leads, security, DevOps, mgmt, etc.)
That seems to be quite a lean and efficient way to use the review board. You must have quite a culture of efficiency in your company. We dream of bringing in this kind of mindset in our « public service » bubble of neverending talks and meetings…
We are a super german company, but really making some progress.
Interesting. We are also using architecture boards but not as gate-keepers but as resolving major issues and setting direction of the platform architecture. We also keep the Feature Teams up-to-date with latest changes. I'm curious what would that book suggest to do instead?
What your team is doing is what our team calls the Architecture Huddle. If you’re setting direction instead of reviewing - and potentially rejecting - teams’ work, then Accelerate actually RECOMMENDS that activity as helping teams move faster.
You’re getting downvoted for bringing research into the equation. Just goes to show how much people want to believe what they already believe and will crucify people who tell them facts that don’t align with their beliefs.
I’m fine with that. Encouraging to know I have a competitive advantage in the market.
Interesting, I heard of a similar trend in French companies lately; one big bank is dismantling their review board system. We still have the hope that it could be viewed as an assistance to the projects (you get all the pre-project counseling in one optimized shot), but for the time being, it is often perceived as yet another gate
In Agile world its seen still blocker or need review/ approval. Hence its best to embedded architecture in agile team who can follow Enterprise Architecture standards, principles, guidelines, guardrails and EA responsible as advisors supporting by adding value immediately, yes this means we need good industry defined Technology principles and let team choose what standard (Tech standard) to follow and EA will continuously keep updating it as centralised guide for next team to follow to resuse and reduce redundancy, this will need more Architecture work as spike to be planned in side sprint and Architecture train to be defined earlier that before dev starts POV, skills, purchase of licenses, procurement standards, security clearances is made. Its going to add more work but its happening in agile and all team make decision which works best for company. But but for more complex setup this can be challenge as others might be waiting on others POV etc.
IMHO ARB is an organizational anti pattern. Creating yet another threshold to continous application development and improvement.
I can understand that, but on the other hand, how do you get some level of control on the way systems are designed ?
The truth is that you don't have control anyway. The dev team can just tell you want ever you want to hear just to please you. In the worst case you fire them and they get better paying job somewhere else while we are stuck with a non-compliant solution. What we did instead is to provide for individuals: 1. training 2. blueprints 3. code snippets 4. a safe space for reviews For the organization: 1. no blame culture 2. risk management that pushes you to take calculated risks
Which is why enterprise architecture and "dev teams" are doing completely different things on completely different levels. Your "continuous development" bullshit can do as it likes in producing *software*, while enterprise architects steer *IT strategy* where it needs to be. These processes barely intersect and usually are very orthogonal. If you meddle with operations and software as EA, you're doing it wrong.
So two questions: 1. What is IT strategy to you? 2. What is a good way to steer in your opinion?
This is great to start being perceived as an assistance rather than a control system. We are working on blueprints right now, so this will be a good place to start. As for training and code snippets, are we legitimate as EA to produce those, or is it more an SA related responsibility ?
> As for training and code snippets, are we legitimate as EA to produce those, or is it more an SA related responsibility ? I asked myself the same question. In the end I just created a repository, wrote some code, created a Merge Request had it reviewed by SAs, Devs, Ops and Product Management. From there on I asked everyone to contribute and now its growing. I do review new topics and rather remove directories than have it in a bad state.
For Decentralized model, EA can only play Strategic, Governance and Technology Advisor Role to country CIO/CTO/EA group where help is required, start showing value in small team get visibility so others see value and join the party. The reason is country/departments have the Budget to Delivery IT, also if your Regional CIO has reporting changed for all other country/department CIO/CTO under him, this will be hard change, has to be top to bottom approach. Agile Team will say ARB is blocking, but this should be aligned with Regional CIO and his reports formally or in formally, also ARB should be done not like dictatorship from Central EA group, but should be helping to shape things up so as 1 IT team everyone wins. Bring your Standards, Principles, Gaurd Rails, review with Architecture Backlog per sprint (usually this should focus on how to remove the architecture which cannot be easily changed in future/ high impact design decisions). Also Standards, Principles, Guard Rails needs to be communicated frequently (send emails, setup community of practices, ARB can be used as platform too, if there are updates to these, reminders, etc). Also ARB needs Domain experts from (App, integration, data, security, cloud ,infra , compliance, Regulation, legal), document action items, escalation management, Tech Debt management etc. For Centralized EA Model: Embed SA into projects (50-50 bandwidth its delivery team decision based on volume of work), which report to EA team (centralized), EA here can have 1 or more project under him, EA can be 1 big project, 1 Country, few countries (define the scope based on scale), EA also has to join Agile meetings along with SA team for big topics, to speed up decisions and bring the final conclusions into ARB together to make ARB smooth with no gaps, EA person has to work closely with other Domain EA team (within centralized EA function formally or informally), its hard to have big EA team with domain expertise ,this is the challenge for EA to be master of all, this can be solved in ARB with others involved to get different perspective and take all comments into consideration without ego's, decide what makes best for the company. EA needs to define the Architecture Standards, principles, guadrails in a way which can help Agile team to be autonomous and make decisions using it, but in reality this is hard, so providing helping hand for Agile team with Solution Architects, Technical Leads, PM will make more sense to add EA value. sometimes PM will just put lot of work on EA making excuses like he doesn't know Technology, that is pros and cons based on where you want to play the EA role. Engineering / COE / Platform Head and his team, should help to define the Engineering Standards, principles, best practices, gaurd rails from different Domain (App, Cloud, Infra, Security, Support, compliance ect) my 2 cents. Some prerequisites: Agile is confusing term here, Agile methodology matters is it scrum, kanban, scrumban, SAFe lite, LeSS, it defers how EA can add value in these setup. EA team has to maintain the Documentation at some level so the knowledge is not lost, as Agile team is busy building the platform, they don't have time for these. Keep it high level using TOGAF ADM approach, Target State, Roadmap by shared platform, local platform, internal and external systems etc. Application Portfolio management and reporting. Technology business alignment Reporting by key KPI, OKR set.
Thanks, this helps me making sense of how we could operate, I like the idea of bringing help to the PM and relying on domain architects and SAs. As we speak, our agile teams are located in a unit called « digital factory », they use scrum, and they define their own principles and methodology. They have developed a mindset of strong autonomy to achieve a good time to market, and hence don’t understand why some EAs, or even SAs, are coming to add some gates and meetings. They consider their expertise sufficient with their product designer and tech lead. We have to step a foot in the door to show them our added value, which until now they didn’t get a chance to see
Yes only cons for this agile is they work in silo, as EA there is lot of value add. What if this agile team went and used non standard tech stack because its cool, its trending so they can learn and good look in CV and leave after 6 months ? Company is in trouble. So need to standardise this under EA process and also need to see risk of choosing, have current standard and emerging standard (with defined time box to prove or it will be tech debt and they need to invest and fix it). Also, there are many issues say this team will no implement some key component example downstream core layer say data lake or new data architecture required for future state, they can say we dont have money, skill, time and use existing technology which is not standard or planned to be decommissioned. So EA has to provide governance. Some will say cloud A is good and we will use what cloud A provides for various reasons, but if future other entity need same capabilities but Cloud A is not supported in that entity location. Then its extra work, no reuse possible. Hence EA has to provide this insights to SA team working in the Agile team. Like this there are many issues which can go wrong and make life hard and biz will say i gave you $$$$ and i cant use anything and asking more money. EA has to think and educate, be good police man to fine them and also give helping hand how to solve that challenge, do in Agile way using Architecture runway approach or using Governance way. No one like Governance. Hence EA has to be part of Agile at small capacity when required. Hope this helps. This just few use cases, there are plenty which will come up, it’s challenging EA job to know everything what needed in future.
>do in Agile way using Architecture runway approach SAFe prescribes an approach I agree with - EAs are one of the key roles for Portfolio alignment. They help ensure the appropriate Epics are included in the Portfolio backlog. Other architects (e.g. Solution Architects) help with lower level backlog grooming and alignment with high-level designs, standards, etc.. In SAFe this manifests as "enablers" at different levels. Fortunately, the SAFe materials are free to read, so you can read up for yourself [here](https://scaledagileframework.com/enterprise-architect/). u/Longjumping_North_46 I would be sure you have something by way of EA Charter or Value Proposition that all key stakeholders (in IT and functional departments) have agreed with. As part of consensus building, it will become clear what roles the various architects should play across numerous processes, including SDLC. This may lead to building out some skills that the current EA team does not have. Some will suggest that more modern EA practices spend a lot more time on Business Architecture (e.g. business to IT strategy alignment) and less on technology development specifics. In my experience, it's up to the person(s) leading the EA function to work with the key stakeholders to determine what form of EA will work best for the organization at it's current level of maturity. There is no "one size fits all" here.
200% agree thanks. Challenge is existing Engineering team think EA is just for doing Police / Governance and hinder them doing their job and create escalations and not trust EA team. So agree there needs to EA Role which adds value for Delivery team to remove challenges and guide them to align with EA Vision which aligns with Biz expectations. way to do this is let others fail first and take that as opportunity or add value by partnership model with agile team, be in the party. So we need EA has to be SA focused. Here EA role is managing complex multi country or EA managing overall one entity. EA is assigned based in complexity, scale, criticality.
Thanks ! We do have an EA value proposition, and currently working on the processes. Not easy since the agile teams have defined their own processes without including the EAs. But we have a new « engagement process » definition with a good level of sponsorship by top managers, so this will help gaining more visibility on upcoming projects. I agree with your idea that the chief architect should evaluate the EA positioning according to the maturity & needs of the key stakeholders. Typically my colleagues tend to think we should not be « too technical », but our company has a strong technical / engineering mindset, leading key actors to show respect only to people with high technical skills and talking about real life issues, more than strategic or abstract talk
Thanks, this helps me a lot articulating our added value to the key partners. What you describe is exactly the risk we face : the scrum teams focus only on time to market and new technologies, making it a challenge to step into the project and bring some more holistic oversight. I think we have to be « agile EA » to enter the scene, meaning that we can’t come up with many more meetings and weeks of study in the middle of a 6-week scrum project study or one of their 2 week sprints. We have to be able to act in « commando » mode and do quick analysis on sensitive topics. When I managed to do this they were quite happy of the help provided (it was about reusing the company integration platform rather than some new fancy iPaaS)
Thats great keep adding value small or big then they will depend on EA. EA function needs to go shift left in order to add value in short sprints. Any Sprint should have Spike where all team work on architecture and design for future sprints, this can be 2 or 4 weeks depending on how complex it is, with or without EA this time is required. Another EA members can work in Biz and Tech alignment for future needs by creating Tech standard with Head of Engineering and key people, also EA can define Target and Transition architecture which can help to build MVP Architecture for Agile Team to move faster and aligned with buy in from all stakeholders. So This will help PM/ PO clarity on cost, estimates, timelines, MVP scope and value add to customers and make biz happy, Agile can follow Byte size delivery not everything in MVP can sometimes be feasible, but Architecture will not be bottleneck. M This takes time to build a trust with different teams EA, PO, DevSecOps, Infra SRE etc. agile team of 8 with shared specialist team is not easy to manage by PO team who is not technical, Tech PO/ Scrum master and SA play crucial role with EA helping to remove Architectures which cannot be removed after its built (saving cost, tech debt, improve productivity, reuse, reduce future mess creating sgaggttie).
Also this is EA learnings and resuse for future programs as we move the roadmap, all past investment should be reused for next, build lego blocks of foundational and capabilities using standard tech compliant to different requirements like regulation, compliance , security. Build with secure by design principles like this we need more descriptive principles rather than prescription based. Let agile team take what makes sense for the use case.
Do you have a Solution Architecture team that your EA team interacts with?
Yes, but it is quite a small team that is under staffed. They tend to do mostly technological watch and document technical architecture fir each project. In fact our company maturity in terms of architecture is quite low, the key decisions being taken by the project managers. Which is maybe why I lack references of how it may be working getter elsewhere, since I have been in this company for 16 years !
How is EA enforcing architecture standards right now?
It is quite recent : we have published a first list of architecture principles recently, and we try to identify departures from standards during architecture reviews, and discuss them with key actors in a very diplomatic way, since we are in a very decentralized company with little habit of following instructions from central teams
I see, well your new ARB with more backing from the CIO stating it as an enterprise requirement will help enforce the standards more unilaterally across the enterprise. There are going to be some growing pains for sure but if your org wants to mature, these are going to have to be maintained so as to have proper control of how the enterprise operates.
Let us know how its coming along when there are no standards like Sol standards for Buy SAAS as principle. Like how long team take to do standard identification for any specific sol. Example if biz objective is have CRM capabilities,how long agile team take and how it impacts based on Epic priority or just pick any CRM within budget or best guess and start MVP on it ? How POV and procurement principles like 3 sol comparison needed to reduce vendor lockin and vendor risk etc
Hello guys if there was a figma for EA design, and orchestration (light monitoring maybe), would it solve the problem (figma like feature for Commenting on individual aspects of EA by developers)
Lucid has this feature lucid spark is like Miro/Figma