A new paradigm for educating the world!

Doesn't have much to do with EA, but I definitely need to share this. EDX is a new teaching paradigm that will make continuing education a delight. MIT, Stanford and Harvard have gotten together to offer courses online for free. These courses are mostly technical in nature so it is definitely worth your time to check them out, I have joined the Cloud Computing course and think it's amazing! 

check it out for yourself! 

https://www.edx.org/

Business Process Mapping

TOGAF has something called an Architecture Development Methodology, ADM, that does a pretty decent job at explaining how to develop the architecture for a project. Ofcourse, this isn't the only thing that TOGAF contains but it is the "big kahuna". Earlier versions of the TOGAF were considered to be more of an architecture process rather than a complete EA framework because TOGAF placed so much emphasis on the ADM. The later versions contain a bit more information on the types of artifacts that should be created thus making TOGAF a more, formally, complete framework.
Anyways, the main topic of my post today is how Business Process Modelling should be the primary task undertaken by an architect looking to solve a problem. There are three main types of EA engagments,
1. The project sponsor doesn't know what the problem is, but knows there is one and wants the Architect to find it, propose a solution and, usually, govern the implementation.
2. The project sponsor knows the problem, wants the Architect to propose solutions and, usually, govern the implementation.
3. The project sponsor knows the problem, knows the solution he wants to implement and wants the Architect to govern the implementation.
In the first two scenarios, the architect has to create a solution. After the preliminary phase is completed, The architect's first task should be to start comming up with a business process diagram. Many a times, just drawing the diagram goes a long way into identifying the problem. You may not even have to propose with an expensive CRM tool if the solution to your problem can be solved by having the front desk call the manager on his cell phone to let him know there is customer who would like to see him/her. There may be many other reasons reasons to implement a CRM, but if the problem you are trying to solve is making the manager aware there is a customer who needs an issue addressed.
What triggered this realization was that alot of systems don't need automated solutions, manual one's work just fine. In Saudi Arabia, for example, if you are a foriegner and want to apply for your spouse's visa you need you get your paper work together and go the the visa office, if you get there before the opening you will find a piece of paper stuck to the outside wall of the office. You write your name on that paper, leave and come back when the office opens. The honor system is used to to make sure no one crosses out names. The officer takes this piece of paper down and distributes number tokens according to the names in the sheet. It's actually quite orderly and a great way to prevent people from queining up for hours to get the visa processed. Come early, write your name and go home. Come back when the office opens and get your token. The rest of the process may be inefficient but atleast this process is quite inventive and it's all manual!

The Goal

The question bothering me recently has been, what is the point of enterprise architecture? Is it to govern specific large scale transformation projects, like a government ministry's etransformation project, or a bank's core accounting replacement project? or is Enterprise Architecture the goal in itself? i.e. the establishment of an EA office, procedures, goals, standards, architecture board, Architecture principles etc. and embedding it into the organizations phyche.
The definition of EA that I like, and there are many out there, is that "EA is a method to help organizations turn strategic plans into operational realities". If this is truly the goal, then EA is not the only method to achieve this, Project Portfolio Management (PPM) also claims to to help organizations turn its plans into realities by  determining the optimal resource mix for delivery and scheduling activities to best achieve them. This is not necessarily exactly the same thing but with a little tweaking it can be made to serve the same purpose.
My view is that applying an EA methodology to a single project has limited benefit for a firm, though large scale projects can benefit from the discipline enforced in the design phase of EA. The real benefit for a firm comes from the standardization of technologies and the agility this inspires. EA should help firms do the right things and do things right, a cliche, but an apt one. This again is limited by the fact that Architects aren't always invited to business startegy discussions.
Most people don't believe EA is technical discipline, and I tend to agree with them, but technology has tinged the way architects work. Most of the architects I know have technical backgrounds, when was the last time you met someone who had an accounting degree and claimed to be an Enterprise Architect?
What we need are more people from business backgrounds moving into the role.