There was also that interesting discussion thread on the Web Analytics group about "Does a web analyst have to know how an I.P. address is constructed?". Although useful, I don't think it's essential and you can read my opinion and those of others in the discussion thread.
A thing leading to another, I got an email that sparkled some interesting discussion about the role of an ebusiness architect. I also realized some of my co-workers don't know/understand what is my role as a "senior ebusiness architect".
So? What's an architect?
Let's borrow from Wikipedia: "an architect is a person who translates the user's needs into physical, built solution. An architect must thoroughly understand the building and operational codes under which his or her design must conform. That degree of knowledge is necessary so that he or she is not apt to omit any necessary requirements, or produce improper, conflicting, ambiguous, or confusing requirements. Architects must understand the various methods available to the builder for building the client's structure, so that he or she can negotiate with the client to produce a best possible compromise of the results desired within explicit cost and time boundaries."As we read this definition, it's obvious it perfectly applies to Information Systems/Information Technology and more specifically, to ebusiness and Web initiatives.
Some caveats (and a legal disclaimer)
In some countries, like Canada, job titles such as "engineer" or "architect" are regulated professions. So officially, I'm not a "senior ebusiness architect", I'm a "senior ebusiness advisor". Just like a few years ago, I tried to explain that I was not a "software engineer" simply because I couldn't use that title.An architect for every soup
There's often confusion around the job titles. Put any of those words in front of "architect" and you've got a new field of expertise and a new career: software, technical, organic, functional... ebusiness, enterprise...What should an ebusiness architect do?
Simply put, my role is exactly that of an architect: take the business requirements and plan for the solution. A bit too simplistic, let's look more closely at that phrase:- take: this implies a lot of listening, communicating and explaining the process that will lead to the solution
- business: have the right interlocutor and that he/she is empowered to take decision/action
- requirements: one of the biggest challenge is the fact that "requirements" are often (almost always!) expressed in terms of "solution". From the requirements, we must strive to understand the initial objective. To take the home analogy, the client knows he/she wants a "3-section with side-panels triple-glass wooden-frame 6 feet by 4 feet window" on that wall, but probably doesn't know how the wall will need to be reinforced to support the 2nd floor. The objective would be something like "The dining room as a view on our garden and we can see really beautiful sunsets. I want the largest window possible as long as it doesn't increase the overall cost of the house more than X$". It's the architect responsibility to read between the lines and translate those requirements into realistic objectives.
- plan: It's also the architect responsibility to work within the constraints of time, budget and quality. This implies a vast understanding of the subject and the collaboration of field experts to gather the elements of the solution and mutually challenge the solution to come up with something as efficient and as realistic as possible.
- solution: Solutions are mutually accepted compromises. That last point is critical: sometimes it's the role of the architect to go back to the client and explain why the requirement can't be met, or why another approach might be better or at least, satisfy a fair percentage of the goal without necessarily constraining future enhancements.