Jeff BramwellDirector – Enterprise Architecture, Farm Credit Services of AmericaVisual Studio ALM MVP@jbramwell :::: blog.devmatter.com

Adventures in…Enterprise

Architecture

Agenda

• History/Team Structure

• What is EA?

• Lessons Learned

• Summary

Let’s Talk!

History/Team Structure

A Quick History Lesson

2008• We hire first Enterprise Architect

2010• We hire second Enterprise Architect – me!

2011• We hire first User Experience Designer – part of EA team

2012• I become Director – Enterprise Architecture• We hire my replacement

2013• We hire first Enterprise Applications Developer (EAD)

2014• We hire third EA• We hire second User Experience Designer• We add three additional EAD contractors to team• UX moves out of EA

2015• We hire fourth EA

Jeff BramwellDirector – Enterprise

Architecture

Enterprise Apps Architect

Enterprise Apps Architect

Enterprise Apps Architect

Enterprise Apps Developer

Enterprise Apps Developer

Enterprise Apps Developer

Enterprise Apps Developer

Our EA Team

Application Development Team

• “Base” team configuration:• Team leader• Lead developer• 3 (or more) developers• Database developer• Quality assurance engineer• Business analyst

• Some variations of the above do exist• E.g. Mobile

• We have 9 AppDev teams (10 including EA)

“Application Architects”

What WE Provide

• Technical vision and direction• Maintain EA roadmap/backlog

• General technical guidance/mentoring

• A common “language”

• Cross-team collaboration and facilitation

• Sounding board for:• Applications development• Business teams• Program office

• Enterprise-wide tools and “hygiene”

• So much more…

We are the team that provides architectural guidance that facilitates the ongoing strategic alignment of

business and technology.

Our Mission Statement

What is EA?

What?

Just because I am an Enterprise Architect,

thatdoes not mean I am an

Enterprise Architect

Architecture Roles

Lead Developer

Courtesy, A Day in the life of an Enterprise Architect, Mike Walker, July 2007, MSDN

Us

How We Spend Our Time

The Architectural Continuum

Startup• Chaotic• No Standards• No Processes• No Automation

Mature• Overly Rigid• Strict Standards• Lots of Processes• No room to “Play”

Let’s play on this side of the line

Creativity and

Innovation happen here

Over time, the system shifts to the

right

Our goal is not to be

here!

Adhere to guidance as best as possible but leave room to

innovate

Lessons Learned

In no particular order

F.O.C.U.S

GOAL: Don’t Overcommit

• Follow One Course Until Successful!

• Examples of focus within EA• Data architecture (governance)• Web architecture• Security• SaaS/Multi-tenancy• DevOps• Quality (across the enterprise)

• No more than one focus/EA

Every Decision Has a Cost

GOAL: Keep Costs in Mind

• EA’s job is to align business and technology

• Business wants to make money, not spend it

• Implementing an EA initiative will take resources & $$$• Moving from TFS (on-premises) to VSO• Migrating from SQL 2012 to SQL 2014

• Choosing a new toolset will take $$$• Abandoning Knockout in favor of Angular• Moving from Visual Studio Test Manager to Telerik Test Studio

• There are other types of cost• Moving a project up in priority means something else isn’t getting done• This might impact the business internally or customers directly

• Ensure everyone is aware of the direct/implied costs when recommending a change• Include the overall cost savings as well, if applicable

• If possible, put measures in place to eliminate/reduce this cost from recurring in the future

Enjoy Some ROI

GOAL: Reduce Chaos/Cost

• TRUTH: There will always be a next framework/library/utility/etc.

• Resist the urge to jump, unless:• It will significantly reduce development effort• It will significantly reduce maintenance/license costs• It postures you for future needs (e.g. compatibility)• There is virtually no cost to do it (e.g. upgrades)

• Define a process for vetting new technologies

Stay on Target!

GOAL: Provide the Guardrails

• Guide toward accepted tools and process

• Implement a Technology Radar• Adopt• Assess/Trial• Hold

• Popularized by ThoughtWorks

• Can also be utilized for other decision suchas training needs

Guidance vs. Standards

GOAL: Be Specific, Be Clear• Distinguish between the two

• Guidance – it’s just that• Allow for creativity/innovation – i.e. some deviation OK• For example: Data Access techniques, libraries, etc.• Provide choices where it makes sense

• Standards• Do not deviate• For example: Security, Server OS, etc.• Provide choices where it makes sense

• Find the right balance• Continually seek feedback

The “Meat” API

GOAL: Work Toward the Vision

• People (“meat”) are the hard part of theequation

• There is no public “meat” API

• Build a shared vision/consensus

• If you’re not on the same page, life becomes very difficult

• Work to build trust & respect

Relationships

GOAL: Earn Respect Across Organization

• Build relationships with:• Business/Product owners• Systems engineers• Network administrators• Developers• Essentially… everyone!

• Avoid the “ivory tower” syndrome

• Schedule recurring meetings with the “business”

• Spend time with the developers

Automation vs. Manual Effort

GOAL: Efficiency & Accuracy

• Automate when/where possible

• Applies to development and EA processes

• Examples:• Scan for dependencies vs. manual diagrams• Automated builds & deployments• Project configuration

• Find the right tool for the job

• Your environment might require custom tools• For example, auto-derive dependencies

Discoverability

GOAL: Provide Timely Information• What good is information if you can’t locate it?• You must “market” your information

• Experiment with various methods

• Motivate others to contribute• Two guiding principles:

• Keep all documentation in same system (e.g.SharePoint, WordPress, Drupal, etc.)

• Must be searchable

• The above principles have helped more than anything

Enterprise Application Developers

GOAL: Get Stuff Done!

• Dedicated bandwidth for items such as:• Version upgrades• Migration to new technologies – examples:• Implementation of enterprise services – examples:• Manage open source (OSS) projects

• EADs must be self-organizing & motivated

• Be the “Poster Child”

• Work well with other teams/earn respect

Models

GOAL: Provide “Right-Sized” Models

• Models are hard!

• Some tools help, none are perfect

• “Enterprise” tools exist but are very rigid

• For a (really) small organization, tools such as Visioare likely sufficient

• For everything else, look for automated scanners• NOTE: You might have to build it (e.g. SystemFlow)!

Learn, Learn, Learn,…

GOAL: Continual Improvement

• Read… a lot!

• Talk to other EAs (inside and outside your organization)

• Be involved with the community• EA User Group/Forum• DevOps User Group• Developer User Groups• Conferences

• Seek feedback

• We do all of the above

Success Criteria

GOAL: Be Successful

• Cultural buy-in

• EA embedded within all teams

• Relationships

• Understanding your business domain(s)

• Keeping abreast of technology

• Sharing knowledge (i.e. removal of silos)

• Continue to push EA

• Feedback (from others)

Summary

• We’ve come a long way• Most everyone knows who/what EA “is” now

• We’re still maturing and…• Growing

• We’re more involved in the (EA) community

• We are all continuing to learn and hone our EA craft

• It never stops

Questions