Cincinnati’s Innaugural CinARC

If you’ve paid any attention around here you know that I just don’t get much swag at these user groups. I dunno. It must be a karma thing. And you also know that I generally leave Tuesday meetings around 8PM to pick up my daughter from the dance studio. So I walk into the office this morning (Wednesday) and Jeff Rollins tells me that I “shoudda stuck around last night because they drew my name.” Apparently he left with a nice web cam drawn two names later. No telling what I couldda nabbed. I’m still not bitter. Really.

CinARC Leon and JoeAnyway, CinARC had its inaugural meeting last night, and what a great start it was. A group of some of the well known folks in the community showed up, and I saw some new faces, too. Leon Gersing, Mike Levy, and Joe Wirtley were scheduled to answer all our questions about what an architect is, and Mike Wood had a few things to throw out to get the conversation started. As the evening progressed the format evolved into a very successful fishbowl, and the crowd included some spillover from the BI group meeting next door. Looking forward to some tech agnostic speak next time as this group should include all sorts of folks in an inclusive forum.

I got a chance to catch up with and meet @MaggiePlusPlus, otherwise known as Maggie Longshore. I also got a chance to catch up with Brad Butts, Dennis Foster, Matt Brewer, Mike Wood, and Dan Hounshell a bit. All in all, about 30 attended BS – Before Spillover. @jengrif showed up BS. Jeff Rollins wrote up his interpretation of the evening, and I’m glad he attended, as he’s been asking me for 3 years what an architect is 😐

Wood led the evening with the question, “What shouldMike Wood this group be?” This community never lacks an answer. Together we’ll make it not just another .NET User Group. Open to different types of technology. And (in informal conversation format) we’ll discuss distribution and deployment models (web/win, thin/thick, mobile), handling the ilities – responsibilities, availability, scalability, performancability, recoverability. Failures. War stories are what’s useful – what’s worked for people in the real world and why. Infrastructure as well as application. Some EAs in attendance. Some Solutions Architects. And some aspiring architects. Broad range of talent. Less eyes-front presentations and more open-spaces conversations. N-tier architectures and implementations. Bring in, say, Josh Holmes and ask, “How would you implement an architecture about X problem?” Bring your problems from work. A respected resource. What do you do when you’re the goto guy and you have no one to goto? Need the sounding board outlet with peer support. Mentoring, but probably not formal. Building a community of folks that you can turn to with questions. Definitions of architect. Presentations on existing architectures and what’s working well for you. Maybe follow it up with an open spaces format. Maybe architect a solution as a group together. Ethics. Tools – what is everyone using, frameworks, etc. What resources and where do people go to find answers. Modeling. Virtualization. Keep it about architecture and not about selling architecture to the business. At least not let it take over the conversation. Patterns. Do we cross over into design? Where is the line? Some design is necessary when coming up with an architecture. The XDDs – X Driven Design – what is the balance of pros and cons. Employment issues. How to better leverage MS evangelists. DP&E – Developer and Platform Evangelist.

I think Mike has a full agenda moving forward, and here’s to you Mike for taking the developer banner forward in the community and finding innovative ways for allowing all of us to engage and take part!

So now our panelists line up for the discussion. Hmmmm.

Introductions: Joe Wirtley, independent, has presented on the topic. Mike Levy an SDS consultant. Leon Gersing with his signature hat, a developer for telligent and has been architecting stuff for a long time. Mike Wood plays moderator. What follows is some of the conversation that I could capture. You’ll have to deal with the poor grammar as I was just working to keep up.

Wood: Do you consider yourself a software architect.

Joe: yes, call hiimself an architect developer. Spans the kinds of tasks. Has an architectural mindset.

Leon: no, a function of the job taken at telligent. A couple months ago, yes. Taking a deep development dive.

Mike: no, don’t wake up thinking “it’s a good day to architect something.” Other roles include sales support or an analyst. Part time architect, full time fraud 🙂 Begs the question, “what is an architect?” Perhaps sales support or business processes are part of the architect role.

Joe: I play the BA role. Is it part of the archtiect role? Dunno, but I have to play the role. Mindset is architecture in spite of the roles.

Leon: a moving target as the business around archtiecture evolves with changing responsibilities and hats. Sometimes the tasks are obvious architecture tasks. Sometimes the tasks are not so obvious.

Wood: do you ever compare systems archtiecture to construction architecture?

Leon: many titles are imposed as marketing features. Architect evolving from old “tech lead” title, maybe to increase bill rates. Then it’s up to the individual to live up to the title and define it.

Mike: OS and MS have archtiecture certifications.

Comment: construction architects don’t build, builders build. Software architects are the same.

Wood: we go fishbowl after pizza. Questions for now.

Joe: focus on business value as the architect needs to focus on both technical and business value. Head needs to be in both places.

Mike: it depends on the granularity of the program you’re looking to address at that time. Every model has a purpose and granularity. If you’re working at a high level of interop between systems then you’re dealing wtih different issues than working through low level application issues.

Joe: Then you’re a technician, but not an architect anymore.

Wood: Throw out terms Enterprise, Solution, and Infrastructure. Take these terms.

Mike: add Data, Business, and Application. Now define ’em.

Wood: Solution covers data and application for a particular solution, say, a check-writing system. Infrastructure is familiar with server products and administration, and networking issues. Enterprise sits above Infrastructure and Solution and understands the pieces as they work together. Business, assumed, should be handled by the architect.

Joe: Solution architect is moving to a broader role as they take on more and more responsibility. Enterprise, Solution, and Infrastructure from the MS gospel. Download my presentation and you’ll find a link to a video that describes the MS definitions.

Mike: EA is the guy working with the CTO/CIO to ensure business and technology is aligned. Infrastructure is the same as has been said. Solution is ambiguous. Business concentrates on the boundary between business and technology. (Joe makes funny face) I’m entitled to my opinion. Figure out what business needs to address market changes. Application exists at the low level on one application. Solution encompasses all apps that address one solution. Application could be a team or tech lead.

Leon: Infrastructure easy. Business easy in this scenario. Application in experience is also the solution architect. I may not have worked in environment where solutions were larger sets of applications. EA understand the entire landscape.

Wood: get these and discuss on the forum. After pizza, do the fishbowl format.

The FishbowlOkay, fishbowl format here we go. Continuing the conversation around “what is an architect.” Looking for agreement on a definition. Again, forgive the poor grammar. And the speakers changed so often I only caught part of the conversation and didn’t keep up with the names.


An infrastructure architect straightforward. Enterprise exists at the corporate level, build or buy. Solution architect doing the data and solution architecture. Make sure the dev team following standards and using patterns.

Don’t think there should be a data architect. Architect deals with the business.

Unless it’s a data warehouse.

Why so many architects? First floor architect, kitchen architect.

Notion of the definition comes from the size of an organization. Can see them blurring and splitting further in organizations.

A solution architect won’t define a data warehouse or data mart.

One quality of an architect is that they can fill many roles.

In what aspect is an architect not a role? When developing code.

It’s really an attitude and mindset. Process to developing software. The archtiect defines the process and doesn’t do the building.

I don’t believe the architect is necessarily the guy that controls the process. He may be a champion of the process or despise the process. If the organization has a process, a product owner, a scrum master, or if the organization is small enough then the title may not matter.

Clearly articulated the “what.” What is a role and can it be defined? I think it can’t.

I think each organization will have it’s own definition. In small shops it will be the goto guy. In a small shop it’s the guy that knows everything.

How far does that go? What about the very large organizations? Is it more than just the goto guy?

He knows the systems. Talking EA at this point. know the systems and learn them. Also mentoring and providing information, and that’s any one of the list. Solution level depends on the granularity. EA gets feedback from Solution. Between all of them some design at individual, and between them make sure they work well together and disseminate knowledge.

Process in terms of scrum, or patterns going to use. Two interpretations of the same word lead to different responses.

Maybe define what it’s not.

Not top management and also not a developer. The role existed before the name. Someone had to give a title because they are so important to the organization. Carry it to the developers and tech leads giving them a vision of what needs to become.

I have a problem with the “goto guy” definition. The amount of technology has grown so much that there isn’t a goto guy anymore. I disagree that the architect is the gunslinger of the organization.

What are the qualities, attitudes, and apptitudes of an architect?

Like the foreman, repeatable patterns, right tool for the right job. Not management, but do know the best way to solve the problem.

Don’t like the foreman analogy. Has to lead more by influence. Not a manager.

Characteristics of an architect. Looking to fill a solution architect role, what would you look for in a person?

I ask theoretical questions. Support a website getting 1000 hits an hour, let’s talk about development strategies. Also drill down and find architects that still code. Some haven’t wrote code in 20 years. They read the right books but make all the wrong decisions. Look for problem solving abilities. “How would you solve this problem?” Drill into patterns that solve the problem.

Look for applciation of conceptual solutions that require experience to understand.

Take a look at my presentation

You keep pimping that

5 aspects – technolgoy, leadership, consulting, organizational politics. [Editor: Joe has a problem counting] It comes back to business. They have to undersatnd the whys. Why? What else did you consider?

Tech lead enforces the architect’s design. On small teams one architect and multiple tech leads. The design was jointly created. Are they all archtiects?

It’s more than just designing the solution. I may take the developer role. When people have problems, I can take them and help find answers. Projects fail because they don’t meet the need, not because they don’t compile.

Foreman works. There will be times that the archtiect may need to manage people for a short or long time. May not write performance reviews. B of A has an EA team of 40 people.

They usually don’t work

I sat in on their meetings and was impressed.

With multiple roles the architect re-architects during implementation because it doesn’t work. That’s the danger of having the architect fulfill so many roles.

If your architects constantly change design during development, that’s a problem with the architect. Opposed to waterfall and understand that design requires flexibility. That’s why I like archtiecture role to also be a coding role in order to understand issues as they arise.

I agree at the small shop level. At the larger shop when the design is laid out if it’s at the method level then it’s wrong division of responsibility. If at the “this layer needs to communicate with this other layer using XML messages and web services” then it’s appropriate. Each “team lead” has control over the actual implementation with architecture having oversight. The coding that the architect does is a POC to show that the ideas will work.

When the architects role goes beyond design and into development…

You have a bad architect and a bad environment

I don’t know if it’s a bad architect

It’s a management problem

Is it the architect’s problem to fix? Or someone else’s problem to fix?

It’s the archtiect’s problem to recognize.

And at this point I needed to leave for the evening. My daughter beckoned. The conversation stimulated so many new thoughts and collaborative ideas. I’m really looking forward to its progression. Make sure you attend next time. You won’t be disappointed.



~ by Andy on May 15, 2008.

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: