File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Design and the fly likes Software Architecture: Working with stakeholders Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Design
Bookmark "Software Architecture: Working with stakeholders" Watch "Software Architecture: Working with stakeholders" New topic
Author

Software Architecture: Working with stakeholders

Joel Neely
Greenhorn

Joined: Sep 03, 2013
Posts: 7
    
    1
Hi, Simon,

Given that architecture doesn't directly tie to tangible, user-visible features, how do you help the business stakeholders understand the value of the time and effort spent on architecture?

Thanks!
Joel
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
Hi Joel, an interesting question! I tend to initially approach this from a couple of different angles, focussing on why software architecture is important (e.g. looking at maintainability, security, performance, etc) and what they perceive the role of a software architect to be. If you do enough listening and exploring, you'll often bring out the horror stories of projects gone wrong. This then provides a basis to explain how some "architecture time" could have helped prevent some of the issues.

On a related note, I've recently been running half-day workshops about software architecture for non-technical people (e.g. project managers, business analysts, operational staff, etc) and they had a much better view of what the software architecture role was all about than some developers I've met! You can see a summary here -> http://www.codingthearchitecture.com/2013/09/18/the_software_architecture_role_from_a_non_technical_point_of_view.html
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

Joel Neely wrote:Given that architecture doesn't directly tie to tangible, user-visible features

I have a hard time accepting this premise. Architecture is about form and function. If a building's form does not support its function, then surely the occupant will notice it. Same thing goes with software. Let's go back to everyone's favorite whipping boy these days: the much maligned (and justifiably so) healthcare.gov website. One of the first things that jumped to my mind when I first heard about the problems plaguing that website was poor architecture. Sure, poor implementation too but I think the lack of functionality and poor performance tie directly back to poor architecture.

Conway's Law states that the structure of a software system reflects the structure of the organization that developed it. Can you imagine the mess that results from 50+ contractor companies trying to come up with a complex system that needs to cater to millions of users and interface with a number of government agencies and private companies? And have that system working in such a relatively short amount of time? I have worked on government IT projects before and I think it's a small miracle that they even got it off the ground when they did.

The section about Quality Attributes in #sa4d alone will give you and your stakeholders plenty to talk about that can be tied directly to architecture.


Junilu - [How to Ask Questions] [How to Answer Questions]
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
Conway's law and 50+ contractor companies ... oh my word!
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2448
    
  28

TOGAF addresses this subject very nicely. TOGAF has the concept of views and viewpoints. Viewpoints represent the concerns of the stakeholders, and differrent stakeholders will have differrent view points. So, let's say you are building a banking application for a brick&mortar bank who is trying to provide online features for their existing customers. You might have bank managers who are very concerned about how easy the application will be for their customers to use. The IT engineers will be concerned about how the application will be deployed and monitored. And the CEO might be concerned about the security of the application(He wants to make customers happy, but he would prefer to have slightly unhappy customers if it meant that he will not lose all their money: D) . You have 3 differrent people who are looking at the same thing but in 3 differrent ways. So, as an architect you build views that addresses those viewpoints. You might produce UX wireframes for the bank managers, deployment diagrams for the IT engineers, and a description of the security mechanisms for the CEO. Of course, you need to make sure the architect addresses those concerns, so you need to create the artifacts that show the developers how the application will address those concerns. So, for the devs you create design docs that have solutions for all the concerns "baked into" the design.
Simon Brown
sharp shooter, and author
Ranch Hand

Joined: May 10, 2000
Posts: 1913
    
    6
Jayesh is right, it's all about expressing the architecture in different ways for different people. Out of interest, how many teams do you see using TOGAF? It's not something that I see much of, except in very large organisations. But then, to be fair, I don't really engage with enterprise architecture teams...
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2448
    
  28

I haven't seen anyone say they use TOGAF, but I've been TOGAFish since I dunno when. I learnt TOGAF because I had been an architect for about 4 years now, and I was looking for a job, and I wanted some certification on my resume. Also, I wanted to get an idea of what other people mean when they say "architect" outside my company.

While studying TOGAF, I figured out that a lot of people use TOGAF in principle. TOGAF borrows a lot from a lot of good practices that people already follow. IOW, TOGAF is basically codification of industry wide architecture principles. So, a lot of people have been TOGAFian in principle, but probably not TOGAFian in the detail. So, if you ask me "do you know what kind of diagram to draw that addresses which features should be built first?" I will say "Umm.. maybe Value Chain diagram.. let me look it up in the book at get back to you". However, conceptually, (or as TOGAFians like to say, in the architecture continuum), I've been following TOGAF, since even before I was an architect. I have drawn diagrams to address specific concerns for specific stakeholders. Have I stuck to to the diagrams that TOGAF reccomends? No

Simon, you might want to look at TOGAF, if you haven't. I haven't read the whole book, but looking at your sample chapters, you might be a TOGAFian at heart. It has it's roots in big enterprise architecture, and parts of it is designed to enable "relay style development". However, the current version of TOGAF is more agile and iterative, and also addresses some of the things that you say. For example, previous versions of TOGAF simply prescribed what kidn of artifacts the EA should create, whereas the current one talks about adding a governance phase that drives you next iteration of architecture work. Which is basically TOGAFian-speak for "make sure the developers are sticking to your architecture, and if they are not figure out why and change your architecture accordingly"
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

Jayesh A Lalwani wrote:It has it's roots in big enterprise architecture, and parts of it is designed to enable "relay style development"


Er, from the book: "Software development is not a relay sport."

The point being that hand-offs are waste and constant collaboration and collective ownership are ways to minimize or eliminate it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Software Architecture: Working with stakeholders