As you may (or may not) have read, I am involved in the local (Seattle) chapter of Iasa first ever IT architecture competition. In my last entry, I was guessing about how prepared the team would be and how the meeting would progress. I met the team last Friday and better understand the landscape now. There is so much I can show them that will accelerate their growth and career, and because there is so much, I may overload them.
For our first meeting, we met in a downtown Starbucks. If you have ever been to a downtown Starbucks in Seattle, you know they are meant to be vibrant and are typically pretty loud. There is intimate seating in places, but only for a few people, not six. My team is comprised of undergraduate and graduate students in the IT program at the University of Washington. All are Chinese nationals and absolutely filled with enthusiasm. My first tactical error was suggesting we meet in a loud place with that big of a group – that much noise, my old ears, and five English as second (or third or fourth) language made for an interesting communications dynamic. Easily fixed--we agreed to meet in conference rooms once weekly. We set a starting time and will be loose with the ending time. This does not fix the other challenge with our communication: the conversation and my probing questions.
As we talk with one another, we typically assume context is understood and our references and three letter acronyms are common knowledge. If we don’t know the meaning of a word, phrase, or acronym, we will likely not mention it or ask what it means, we’ll let it slide and try to understand through the conversation or look it up after the conversation. An example I faced this week came from the use of COE. I was in a meeting with a team that had a new team member who had recently joined the company. The term COE was tossed out and everyone was nodding expect the new person. The person asked what COE meant and the other team members starting talking about how and when COE is applied, examples of when it was applied and anecdotes from their past experience. All the new team member wanted to hear was that COE (in this case) stood for correction of error. I have to be careful to speak clearly and to speak up, and try to limit the use of common slang and TLAs. I also have to assume these students do not have experience delivering so I need to provide a 10,000-foot context and 1000-foot detail.
My task before we meet again this Friday is to give them an example of what an architectural engagement may look like. I’ll explain what I do and what I use to capture context and requirements; what checklists (frameworks) I use to make sure I have thought of everything, and what mindset I try to have as I start an engagement.
The problem statement they are trying to solve suggests that this is a brick-and-mortar retail company with a membership function. I’ll describe how I would research the industry and sub-industry first to find out who the leaders are, what group has analysis for the sector and what types of challenges they face. In this case, I would likely start by looking at SEC 10K statements for Costco, Sam’s, and REI and try to understand what each company has told shareholders they are doing this year and what challenges they face. I would look for news about these companies over the last year and look at what companies are being bought by each of these groups (if any). I would then take the requirements and try to map them to the goals the company described to their shareholders. Then, I would ask myself why. Why does this company think that this is a problem that needs solving right now? If I can’t do that I run the other way. Fast.
My next step will be to describe how I expand the requirements by meeting with stakeholders to determine what success looks like and what metrics can be measured to show what level of success is being met. I’ll describe how I capture constraints by understanding the governance and processes the organization has. I’ll ask if the organization has an enterprise architecture (EA) function, how procurement works, how the IT and IT operations groups work, what most development work is done in, etc. I will also ask when this solution will be used and tease out quality attributes that we will focus on. Since there are a lot of quality attributes and there are trade-offs between some attributes, I will narrow the list to a set of important ones to focus on. A good example is security. Everyone wants security--the question is how much security and what are you willing to give away for your desired level of security. There is cost and time, but there is also a tradeoff on usability; the more secure the more cumbersome the solution will likely be.
I’ll likely show them examples of customer journey mapping, PBAAM, Zachman and TOGAF. Too much for our second meeting? We’ll see.