jump to navigation

Enterprise Architecture: A Case Study from Software Development June 26, 2012

Posted by 8952chavezr in Enterprise Architecture.

As a software engineer, it’s interesting to see the choices that the business and IT make with regards to the tools we use throughout the development lifecycle of our products.  I work for one of the largest software development companies in the world.  However, the IT infrastructure that supports the developers does not always seem to portray that fact.  Teams across the organization use different sets of tools to accomplish the same things, such as requirements and defect tracking, integrated software builds, document reviews, code analysis, etc.  Although the products the teams are developing are very different, the process is the same and the teams have the same needs in adhering to the process.  With Enterprise Architecture, the organization can support established processes and help grow the processes to be more efficient.

As described in the Gartner report “Guide for Determining EA Business Value,” Enterprise Architecture has to consider both short-term and long-term results.  In our case, it seems that many of the decisions were made for the short term to help support new processes.  A need arose, and someone made a decision to solve it without much thought to the future.  For example, teams throughout the organization are adopting the Agile methodology for developing software, and there are many tools that support this effort such as Rally, Scrumworks, TargetProcess, VersionOne, XPlanner, etc.  The issue here is that the effort to adopt Agile rose up from the individual teams and only now is leadership paying attention.  Because leadership has vision across teams, it is up to leadership to take notice of the individual efforts and harness it to standardize the set of tools.  More importantly, leadership needs to understand from where new trends arise to stay ahead of the engineering teams or at least on the same track.

Slowly, leadership is making strides toward this goal.  They have realized that the application landscape is too wide-spread.  This is insight an application blueprint as described by Rohloff can give us.  Knowing what applications are in use by different teams, they can understand how best to proceed.  Many of the tools used in Agile planning and execution are very similar.  Each team will have preferences, but EA needs to take a larger perspective.  It is not just about what need the tool fulfills but what other problems it can help solve.  IT and business leaders should analyze opportunities for integration so the tool builds up the data landscape.  This way, the tools can deliver much more than data.  They can deliver information such as where teams spend most of their development time (documentation, coding, fixing defects, etc.) or how the process can be changed to better suit our needs.

In the case of the software engineering teams, the organization has already defined processes to help develop software in a regulated industry.  The process is robust but it is based on the waterfall approach to development.  It needs to adapt to the Agile methodologies that teams are implementing.  This will affect many parts of the organization and is a great place for Enterprise Architecture as described by Gartner to step in.  Although much of the friction in adapting our process to Agile manifests itself at the application level (e.g. the requirements tool is too strict and doesn’t let us refactor requirements easily sprint to sprint), Gartner understands that the engineering leaders and IT first need to understand the business, the information, and the technology approaches before prescribing applications.

In terms of the Enterprise Business Architecture, the organization has already started to change how people are organized and how the different groups such as engineering, quality, validation, and support interact.  Some groups are more integrated than others, but still there is plenty of work to be done on the process side.  For example, teams are still trying to figure out what tools should be used for tracking defects and how defects fit into the Agile process.  The teams need to figure out and leadership needs to guide them how to make sure defects are given the proper attention in the fast paced attempt to deliver new and better features.  This means support and quality need to work closely with engineers to find the source of defects and track the progress of the fix within the Agile paradigm.  As the process matures, leadership needs to make sure that teams adhere to whatever is decided and that the teams are properly trained.  With the business aspects in place, only then can teams begin to form technology and information architectures that support the business people, organization, and process.

In terms of the information, leadership needs to define the data that are critical to running Agile projects throughout the entire life of the product.  At this point, they have identified metrics, which is a good start.  However, it is still not clear if everyone truly understands what the metrics mean.  This is a miss in the business architecture.  The process is not clear.  Also, the information model needs to be put into perspective so we know how different parts of the organization interact with it.  In terms of technology, we need to identify a common platform that can be used across engineering teams.  This will save the IT department time and money because it is clearly easier to maintain a common set of tools than a whole host of different ones.  That is, when the tools are adaptable to different technology stacks that the engineering teams use for development.  Given these three pieces (business, information, and technology), IT can begin to develop applications that can bring the pieces together to support the process and help it mature.

For example, many teams in our organization use Hewlett Packard’s Application Lifecycle Management tool to track requirements, test coverage, and defects.  There are other teams that use other tools, but the leadership is moving towards HP.  In terms of the Agile process, leadership is leaning towards Rally, and they are investigating how to integrate Rally and HP to improve the process around tracing requirements and defects to user stories and combining metrics around coverage and team velocity.  They are even working with Rally developers to leverage the HP APIs to tap into the data.

In bits and pieces, the IT and leadership teams seem to be moving in the right direction.  However, there is more focus on the technology than on the business architecture or the information architecture.  Without those, we can only go so far.  In this case, IT will only be a set of applications we use instead of an agent for change.  Still, it is a difficult task to develop and roll out new processes when teams are still expected to deliver on commitments.  In Agile circles, many experts tell teams that adopting Agile will feel slow at first but not to be discouraged.  I believe this goes for EA as well, which is why we need to understand short-term and long-term goals.  We can use EA to support the change that is taking place regardless of EA efforts, but we must also figure out how EA can take control of the change and help guide it in a more manageable fashion.







No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: