• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Software Architecture: Working with stakeholders

 
Greenhorn
Posts: 11
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
sharp shooter, and author
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Simon Brown
sharp shooter, and author
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Conway's law and 50+ contractor companies ... oh my word!
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1913
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
reply
    Bookmark Topic Watch Topic
  • New Topic