Browse > Home /

What is a Architect?

May 14, 2008

 I attended the first meeting of the new Cincinnati Architect users group (CinArc) to find out the answer to this question. I have been struggling with this question for a long time. Since this was the first meeting, there was a lot of discussion about what the group should and should not be. Attendees did not want a place to just sit and listen to speakers. They wanted a place to openly discuss the issues, challenges and technologies that come with the role of Architect. Yes, I said ‘role’ not ‘title’. More on that later. The format of the meetings is still not totally decided, but the format of a ‘fish bowl’ style of discussion group worked very well for last nights open discussion on this topic. It also kept the conversation on track and under control with 20+ people there.

What is a Architect? Is it the guy that wonders the halls with a chip on his shoulder and thinks he has all the answers … Yes. It is the guy who sit quietly in the corner cube and know how everything works … Yes. It is the guy that everyone looks to for technical leadership … Yes. Is it the guy  who works with the business team and the development team to deliver a solution to a business need … Yes. I listened to a lot of opinions on what people considered a architect to be. Here are some of the qualities of an architect that come out in the meeting:

  • Knows the value of business and how to work with them to provide solutions
  • Bridges the gap between business and IT
  • See the ‘Big Picture’ and keeps everything on course
  • Advocates change ( In technology and business)
  • Mentors
  • Designs repeatable solutions
  • Defines processes
  • Creates conceptual solutions to prove concepts
  • Codes

These qualities can be boiled down into 5 compentencies of an architect

  • Technology
  • Leadership
  • Consulting
  • Organizational Politics
  • Business Stragegy

Many companies use roles as titles to help define an individuals value to the company. I think this is where the definition of an architect gets confusing. It can be defined differently based on the company you are working for. A architect at small company A might only be considered a technical lead at large company B. People can be quick to say that they are an ‘Architect’ because the title adds value to them within the company. It can also mean a higher pay scale and more respect, who doesn’t want that. This is partially how I defined an architect, but after last nights meeting I have a different view. Architect is a role that is played on a project. I might be a architect today on a project, a business analyst tomorrow and a coder the next day. Do I have the qualities and competencies of an architect? Yes (depending on who you ask). Should I have the title? No. I move from project to project in my consulting career and may serve as architect on a project or I might just be joining the team to help out with coding an application that has fallen behind schedule. I could even move to the database and being doing tables and stored procedures. The point to my rambling is that we should not define ‘What is a Architect’ just based on technology, but define what are the qualities, skills and competencies of the individual that plays the roles of architect on a project.

Architect vs. Designer/Technical Lead

This can be a tough distinction to make depending on the size of the company you work for. Smaller companies and projects will blur the line between the two just because there are not enough people to clearly define separate roles. I think the distinction between the two is made by the qualities of an architect listed above. An architect can do the technical lead role, but brings more to the table along the lines of business knowledge and the ability to understand what the business wants, work with them to find a solution and understand the costs and ROI involved in the solution.

Types of Architect

This can also be tough distinction depending on the company or project. The meeting produced the following list of types:

  • Enterprise
    • Strategy
    • Sees and understands the ‘Big Picture’ for a company
    • Oversees all applications and infrastructure
    • Works with business leaders (CFO,CTO,CIO)
  • Solution
    • Oversees multiple applications and integration
    • Develops solutions to meet business needs
  • Infrastructure
    • Servers and sever software such as Exchange
    • Capacity planning

———————————————–

  • Data
    • Database and data
  • Business
    • Works with business to improve process and workflow
  • Application
    • Technical lead
    • Coding standards
    • Application specific detai

The separation between the top and bottom three is because the bottom three could all be considered part of the top three depending on the size of the company or project.

These are just my thought on what was discussed in the meeting. Maybe they helped you answer some questions. Maybe they raised more questions. What is a Architect? It will vary depending on who is defining it. To me an architect is a person who can wear many hats and work with business to clarify the ‘Big Picture’ and create solutions that meet needs and provide value to the business. Don’t worry about achieving a title, worry about being good at your job whatever hat your wearing that day.

 

Thanks to Mike Levy, Leon Gersing and Joe Wirtley for an excellent meeting. Joe will be presenting ‘Pragmatic Software Architecture and the Role of the Architect’ at the May 21st Cincinnati Programmers Guild meeting if you are interested. Check out their website for more info. http://cincypg.org/.

Also checkout the Cincinnati .NET users group site for more information on the CinArc group and the new CinArc forum. http://cinnug.org/. Hope to see you at the next meeting.

 

- Jeff

 

 

 

 

Sphere: Related Content

Written by Jeff Rollins · Filed Under Information Technology | 1 Comment 

Expanding Your Box

April 15, 2008

My wife and I were sitting on the couch the other night and she was complaining that her sweat pants were fitting to tight and cutting into her stomach. Oh did I mention that she is seven months pregnant with our first daughter. Anyway, we were sitting there talking and she suddenly asks ‘Don’t you have sweat pants?’. I said ’sure’ and she went off to look in the closet. One thing you should know is that even pregnant, I have still have 100+ pounds on my wife. She came back later extremely happy. She had found a pair of my sweat pants and had them pulled up over the baby bulge and fitting comfortably. She looked funny, but she didn’t care. She had solved her problem.

Why do I bring this up? My wife is one to follow her usual processes. Clothes don’t fit = go shopping. She has bought her share of materity cloths, but is becoming more concerned about saving money. She had a problem, but didn’t want to follow her normal process and go shopping. She began thinking outside her ‘box’ of solutions can came up with something that resolved her problem and saved money. (Yeah!)

When developing solutions to IT problem, it is easy to get stuck in your ‘box’ of solutions. It is easier to stay in your comfort zone and create solutions based on what you have done before rather than venturing out and trying new things. I fight with this all the time. I recently had a client that needed to add an admin page to view user account information. They did not have reporting or direct access to the database. If I add a page to the site, then I have to secure it from other users. This can quickly add up to some development time doing the standard solution. What if I extend my thinking outside my ‘box’. They have SharePoint which is used to feed list information to the web site. Why not add the view user page in SharePoint? Security is already setup and they know how to use it.

With the pace that technology and development tools are changing today, it is hard to keep up with everything. It seems like there is a ‘best new way’ of doing something each year. Don’t get comfortable in your ‘box’. Try new technologies. Think of how this new tool can be used to solve problems in place of your old way. Read articles, attend user groups and talk to other people about the new technologies. Get an idea of what they do and how they might be useful to you. You might be surprised on how well they ‘fit’ your problems and can be added comfortably to your ‘box’.

Jeff

 

Sphere: Related Content

Written by Jeff Rollins · Filed Under Information Technology | 2 Comments 

Don’t Make Reporting Just An Afterthought

April 10, 2008

 When your faced with all the planning, designing and development involved with building a new application, reporting can just become an afterthought on the project schedule. I’ve been on many client projects where reporting is just a week slapped on the end of the project schedule. “We just need to create a few reports and we are done.” This is not true if your building a system of any size or complexity. Ask yourself why the system is being built. All that work to store data and build an interface to input the data, what is it all for? It is to create reports for the business to analyze how the company is doing. A company runs and survives on the quality (and quantity in some cases) of it’s reporting. CEO’s and business leaders rely on these reports to validate the health of the company and steer it’s direction.  Do you think they want to hear that everything they rely on was just and afterthought!

Reporting systems can get really complex when you are dealing with business people who like to ’slice and dice’ the data. It seems like they want 20 reports to slice the data every way possible. Executives don’t want all the detail, but want everything summarized, categorized and broken out by time. Once the business hears about a new system in development, requests for specialized reports above the “10 standard report” you planned can drive development into overtime. The work loads increase, but the amount of time does not. Add on top of that the need for securing the reports based on roles, teams or other categorization. Extending your application security model to include reporting can add time to your already crunched project schedule.

 You might think that just starting work on the reporting system earlier will give you plenty of time to address the issues above. That is true, but starting reporting to early in the project schedule can cause other issues. If you start development earlier you will need to plan for reporting to take more time. SAY WHAT! If the main application and database is still in development, things are going to change. Fields are changed, flags are added, data is incomplete. All these thing effect the ability to create a correct report the first time through. As the design of the application changes, reports will need to be changed also. This takes more time and extends the reporting schedule.

 There is a positive to starting reporting early. The reports that are created can be used to help validate the system in development. I worked on one project where the business leaders kept coming to me and telling me that the reports were validating were wrong. As I analyzed the data, I found problems with the interface and/or database. Once the issues were corrected, the report was correct. Having reports to validate the system during development can be very useful, especially if you are migrating records from an old legacy system to a new system. Making sure you have all the data and you can match numbers from the old system is critical.

  

The point of this post is to get you thinking about issues around reporting that may cause delays in your project schedule. I’ve brought up a number of problems, but what can be done about them? Here are some suggestions.

  • Don’t make reporting an afterthought. The reporting system can be as critical and complex as the application.
  • Allow enough time in your schedule for proper requirements from business leaders. Make sure you are meeting their needs.
  • Allow time to do proper architecture and design of the reporting system. Factor it into your security model design.
  • Design reports that meet the business needs. A report no one reads is a waste of time.
  • Combine reports where you can. Create a single report with more parameters to allow the business to ’slice’ the data without you needing to maintain 10 copies of a report for different users.
  • Write efficient code. If your using sql, spend the time to make sure it if quick and efficient. Speed counts.
  • If you are replacing a legacy reporting system, make sure you analyze how the old reports where put together. You may need to match those numbers with the new system.
  • Work with business leaders and executives to make sure you are providing the information they need in a format they can use. If they can read a report or two and get everything they need to know, they’ll love you for it and it will help validate the cost of your reporting effort.
  • Know you data. I tell anyone who writes reports for me that they can’t write quality report if they do not know and understand the data. SQL is a language that makes it very easy to get the wrong answers.
  • Validate your data. You can’t get a correct report with wrong data. Test and development systems need to have real data and lots of it.
  • Set expectation with leadership. They need to understand why extra time (and money) is need to create a proper system.

 

Proper reporting can be the lifeblood of a company. Don’t make it just an afterthought.

 

Jeff

 

 

 

 

 

Sphere: Related Content

Written by Jeff Rollins · Filed Under Information Technology | 2 Comments 

Why Cats Don’t Make Good Developers

April 2, 2008

Here at LUCRUM we are always looking for ways to provide the best value to our clients. Outsourcing development to India and China can be difficult and is becoming more expensive. We have been conducting research into a new development model to provide our clients greater value for their IT dollar. Our research unfortunately has not returned the results we hoped for, but I thought the results of this extensive research should be shared. Here is why cats do not make good IT developers.

  • Regular flea dips required to squash bugs
  • Excessive requests for nap time cause productivity problems
  • Each one thinks they write purrrrrrrfect code
  • Keep chewing on the mice
  • Tuna breath
  • Delays due to periods of hyper-activity (note to self: catnip *AFTER* work)
  • Equipment gummed up with hairballs
  • Design meetings often result in a lot of hissing and caterwauling
  • Sharpening claws on office furniture
  • Don’t get along with the new dog application testing department also being researched. Research to be published later.
  • Team management forbid from bringing tuna for lunch. There was an incident. Wasn’t pretty.

 

Bringing the lighter side of LUCRUM- Jeff
 Lily is expert in .NET, SQL Server and is learning SharePoint 2007
  
Sphere: Related Content

Written by Jeff Rollins · Filed Under Information Technology | 4 Comments