adventures in enterprise architecture
TRANSCRIPT
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