adventures in enterprise architecture

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

Upload: jeff-bramwell

Post on 18-Aug-2015

160 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Adventures in enterprise architecture

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

Adventures in…Enterprise

Architecture

Page 2: Adventures in enterprise architecture

Agenda

• History/Team Structure

• What is EA?

• Lessons Learned

• Summary

Page 3: Adventures in enterprise architecture

Let’s Talk!

Page 4: Adventures in enterprise architecture

History/Team Structure

Page 5: Adventures in enterprise architecture

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

Page 6: Adventures in enterprise architecture

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

Page 7: Adventures in enterprise architecture

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”

Page 8: Adventures in enterprise architecture

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

Page 9: Adventures in enterprise architecture

What is EA?

Page 10: Adventures in enterprise architecture

What?

Just because I am an Enterprise Architect,

thatdoes not mean I am an

Enterprise Architect

Page 12: Adventures in enterprise architecture

How We Spend Our Time

Page 13: Adventures in enterprise architecture

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

Page 14: Adventures in enterprise architecture

Lessons Learned

In no particular order

Page 15: Adventures in enterprise architecture

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

Page 16: Adventures in enterprise architecture

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

Page 17: Adventures in enterprise architecture

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

Page 18: Adventures in enterprise architecture

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

Page 19: Adventures in enterprise architecture

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

Page 20: Adventures in enterprise architecture

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

Page 21: Adventures in enterprise architecture

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

Page 22: Adventures in enterprise architecture

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

Page 23: Adventures in enterprise architecture

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

Page 24: Adventures in enterprise architecture

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

Page 25: Adventures in enterprise architecture

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)!

Page 26: Adventures in enterprise architecture

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

Page 27: Adventures in enterprise architecture

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)

Page 28: Adventures in enterprise architecture

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

Page 29: Adventures in enterprise architecture

Questions