As the size of your development shop and organization grows, being able to align the needs of the business with technology grows ever-important. Having been involved with our company's Enterprise Architecture practice since the early days of its inception I have had the opportunity to grow with the team, which I now lead, and have seen what works - and what doesn't - for our organization. Regardless of whether you are part of a small startup shop or a 20,000 employee organization, there is a need for a focus on Enterprise Architecture.

1. Jeff Bramwell
Director – Enterprise Architecture, Farm Credit Services of America
Visual Studio ALM MVP
@jbramwell :::: blog.devmatter.com
Adventures in…
Enterprise Architecture

2. Agenda
• History/Team Structure
• What is EA?
• Lessons Learned
• Summary

3. Let’s Talk!

4. History/Team Structure

5. 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

6. Jeff Bramwell
Director – 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

7. 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”

8. 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

9. What is EA?

10. What?
Just because I am an
Enterprise Architect, that
does not mean I am an
Enterprise Architect

11. Architecture Roles
Lead Developer
Courtesy, A Day in the life of an Enterprise Architect, Mike Walker, July 2007, MSDN
 Us

12. How We Spend Our Time

13. 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

14. Lessons Learned
In no particular order 

15. 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

16. 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

17. 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

18. 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 such
as training needs

19. 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

20. The “Meat” API
GOAL: Work Toward the Vision
• People (“meat”) are the hard part of the
equation
• 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

21. 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

22. 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

23. 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

24. 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

25. 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 Visio
are likely sufficient
• For everything else, look for automated scanners
• NOTE: You might have to build it (e.g. SystemFlow)!

26. 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 

27. 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)

28. 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 

29. Questions