When Enterprise Architecture is known as Dr No

IT Enterprise Architecture acts as a forward-looking, unifying agent across teams and disciplines. The architects generally own the company's future direction and target state.  EA operates as one of the few groups that see all facets of a company's software development, IT Operations, governance, security, best practices, 3rd party integrations, and more.

This cross-cutting responsibility can often put EA in a position where they are pushing future states or constraints that make software development and business process automation even more complicated.  Enterprise Architecture can end up being viewed as pushing solutions driven by NFRs that deliver and business may only be tangentially aware of.  They often deliver designs and mandate approaches that are based on technology and platforms that do not yet exist in the enterprise. This can cause delivery and business to view architecture as an impediment to progress.  EA are the ones that always say no. 

Architecture can help the company and teams.

I worked at a place where a team had 2.5 times the data that would reliably work in a cloud vendor's product.  It was a hard limit. Architecture told them in no uncertain terms, that they should not use that database product.  The team ignored the advice, split the data into 1/3rds, and deployed 3 instances of the database.  One of their 1/3rds filled up with data a month later and crashed the system in an unrecoverable fashion.  They should have listened to Architecture.

Architecture mandates can freeze all progress

I worked at a place where the company created an "everyone will move to our internal container platform" mandate.  The architects delivered the message. It turns out that the internal container platform wouldn't be production-ready for 6-9 months.  Everyone with a delivery date inside that window was forced to do shady and under the table type of work.  

Video

Warning Signs you may be Doctor No

• Teams are delivering and deploying non-conforming or dangerous software without architecture review. The team is actually wrong here. Someone on the team decided that it was better to ask forgiveness than beg permission. You need to dig in to understand why they think architecture's negative feedback was invalid. That may be all they see.
• The design uses resources that aren’t available. Teams are told to use patterns that won’t exist until after their deliverable date. Solutions rely on infrastructure that does not exist.  
• Teams are surprised with NFR work done in less than 3-6 months.  This often isn't architecture's fault. They end up being the ones that have contact with the teams and end up broadcasting this late in the process when it is obvious there are problems.  Architecture becomes tainted as a proxy for the compliance, governance, or another team that creates the mandate.
• Teams hide from architecture
• Teams refuse to do work until architecture appears.  You will see this when teams have had to stop work or redo work based on architecture changing its mind.  Architecture is always evolving which can leave teams playing catch-up to get something out the door.
• No one can make a decision in design meetings. 

Groups have Different Roles and Goals

Architecture can get the name Dr. No because their role is different than that of the Delivery teams or the business partners.  Architecture often doesn't make clear what the top priorities are so it appears as if Architecture continually changes its mind about what's important. They can also suffer from this because they act as proxies for others taking the blame for other groups.

• Architects
• Always designing for target state with a look forward mentality
• Worry about compliance and regulation, anticipating changes based on the changing landscape.
• Have a 1-3 year horizon
• Business
• Want complete flexibility to make changes at any time.
• Wish to be immune to the limitations technology places on them.  At the same time, they will often create End User Computing (EUC) where they build their own platforms because IT is too slow.
• Their planning horizon is normally the current fiscal year. Their planning horizon is next year in the last two months of this fiscal year.

Everyone's view of architecture is different.

Management, the delivery teams, and the architects themselves view the architect's primary roles and restrictions differently.

Executives view EA as

• Agent for Data Governance
• Agent for Security Governance
• Agent for Standards
• Single TouchPoint for communicating future work based on corporate NFRs and NF goals.
• Augment the skills of teams when they have issues. This may or may not be possible depending on the workload and the operating level of the architects. This is most common with Solutions Architects.
• Architects have visibility into detailed delivery and operations team activities.  This is generally not true because of the number of teams supported and the way some team decisions are semi-opaque to outsiders.
• The business can sometimes convince Sr Management that Architects are in the way, slowing down progress and that they are complainers pointing out security and process failures. Entire architecture departments can get blown up over these issues.

The delivery and operations team view EA as

• A place where all the hard decisions or integrations can be kept.  They can use EA as a lever against others, often while complaining about EA involvement in their own project.
• The place where oh-no mandates come from.  Architects often deliver the Non Functional or Operational or Security or Audit or Compliance requirements that teams claim come out of the blue even though they've heard it before. 
• Delivery or operations teams may view external architecture as not accountable to the same pressures they have. This is because architects are often located external to the teams to protect them from internal pressure.
• Architecture can be a rhythm breaker by reminding teams about the go-forward architecture that has to be done. They may also find that an EA decision removes the easy path.

Architecture views itself

• They own/push for the beautiful new world known as the target state.
• They can act as a check or balance between the various partners. 
• They can mentor teams or individuals on how to do better at their craft or better at having a holistic view.
• Architects suffer from limited authority. Delivery and operations can often to the business or executives with the "we won't make the date" reason for not implementing architecture recommendations.
• Architects often suffer from limited visibility into the actual details of how something is going to work. They often know conceptually but don't see enough to understand the negative implications of individual decisions made by the team until after they are implemented.

Rehabilitating Architectures Name

You may decide none of this is required.  I personally think Architects can be more disciplined about some of their work without becoming the process wonks that scare people.  Possible approaches include. 

• Attend business initiative meetings.  Push to be a full lifecycle partner with the business.
• Create regular architecture cadence with developers and testers.  I had an Architecture director tell me once that regular state of architecture presentations would be a waste of time. I have found them to be useful. 
• Pick the top 5 deliverables for Architecture for the next 6 months and broadcast
• Make Compliance and Governance carry their own water.
• Articulate where work comes from - data security, auditors, external threats, regulators
• Identify value to dev teams - Allocate a percentage to that
• Identify value to senior management - Allocate a percentage to that