Tools for EA

Suggested pre-read

EA program for organization - from kick off to acceptance

What tools do you need as an EA? 

Fortunately there is an easy answer to it. You need EVP suite - Excel, Visio, Powerpoint - and that's all. 

Don't misunderstand me. I am not saying you should not / could not / would not try out different tools, evaluate them, tailor them for the use in your organization etc. You most likely will do all of that and much more. I am just saying that you need only EVP suite and nothing else. 

Let me go out on a limb and suggest that you do not use anything apart from EVP (in any of your official communication) till EA practices have fairly well established itself in the organization. Any other tool, could possibly trigger a war of opinions (leading to a lengthy product evaluation, POC, evangelizing cycle etc) that will take the focus away from the business problem and take the whole argument and limelight to the new product. No product will be a silver bullet to all problems. The product will fail under the pressure of expectations - ok, let's tone it down a bit - it might fail. And that failure will be seen as a failure of the EA program - very unfairly but in a very real practical sense. 

If you want to get in touch, you can look me up at Linkedin or Google + .

Enterprise Architect Program for organization

The intended audience of this article are Enterprise Architects who are just starting with the role or are still going through the early phases and trying to establish EA practice in their organization.


From kick start to acceptance

1. First seek to understand. 
1. Don't do EA for EA's sake. Really seek to understand what clients want. Do they need and EA program to solve something critical to business. 
2. That might mean much more than having meetings and workshops. Use your experience as a seasoned professional to understand the enterprise, business strategy, actual stakeholders, pain points of the business, the key stake holders etc. Form a very clear idea of what needs to be addressed. Both in long term (no more than 3 years) and in short term (no less that 6 months). 
3. Put down the "problem statement" in as simple a way as possible and no simpler. Get the key stakeholders to write it down and / or be a part of the process where it is articulated and circulated. It will make it much easier for you to get them to endorse the problem - and lend their support to EA program should they choose to have one to solve the problem.  
4. Limit the scope of the "problem statement" by clearly calling out what will be delivered, and what will not be delivered. 
2. Once you have got the "problem" nailed down - please take that statement with a pinch of salt, for the "problem" statement is never really nailed down and any EA will be naive to not have periodic reaffirmation of the problem statement from the key stake holders - start by working backwards
1. What information do you need to solve the problem? When do you need it by? Who will provide it? Who controls the information? Are the providers and controllers of information bought in to the success of EA program? Does the EA program work against the vested interest of any of these key enablers? 
2. How do all these information link with each other. Which information is input to which decision which in turn leads to which information. This interrelation of inputs leading to the answer to a specific question is a framework. 
3. Pick a framework The different generalized framework are Zachman, TOGAF etc. The generalized framework - if you choose to pick one - is only the starting point. 
3. Don't succumb to the pressure of having to start with a solution. A solution - enterprise specific and unique to each enterprise - will emerge in due course of time if you start with a framework and let it evolve. 
1. EA solutions will be expected to fit the enterprise and it is not enough for them to be good for a project. 
2. It is better to have a solution that is good fit for the enterprise and might not fit all the projects like a glove. 
3. The trick is to come up with a framework that works for the enterprise and has extension points where the individual projects can put in their specific extensions, should they need to. 
4. Fetch data to feed into the framework - and hope it will lead to an answer. 
1. If you have worked hands on with technology till now, this is perhaps the most difficult mental blocker / challenge that you will have to face. For the first time in your career perhaps - the success of your job does not depend on your being able to find the right technology / api / tool / software. There is no right answer. At least there is no way to prove immediately that the answer that you get to, is right. 
2. Once you have defined the "problem", scoped it, closed on a "framework" , it is all about getting the correct, sufficient and relevant information to the framework. The solution might come from the management, from the production line, from the domain etc. 
3. So, plan that out. List down what you need (information, statistics, report ...), from where do you need (stakeholders, production line, chief executives, ...), how do you want to collect (interviews, workshops, online surveys ...). Determine the resources required to collect this - human, tools, archiving etc. Identify dependencies, key milestones. Put down in a plan. 
4. Go. Execute the plan.   
5. In an ideal world EAs output might have been 100% correct. In practical world - with moving business scenarios, transient business priorities, inherent issues around correctness of data - expect errors and educate key stakeholders to expect errors as well. 
1. It is another mental blocker / challenge that folks from software technology background will face. Those who are used to see their solutions compile, execute, see the solution solve the problem and be able prove that a problem is solved - will find themselves grappling with the concept that what they are striving for is "roughly right" and non demonstrable solution. 
2. In fact it is a sure set recipe for failure in all but the smallest of enterprises for an EA to strive for a demonstrable solution. The output is intended to set a broad direction. It can never be correct until there are implementations which actually take that broad direction forward. 
6. Know where to stop 
1. Whatever you do as an EA has to be reusable. 
2. Whatever you deliver as an EA has to be applicable to multiple projects (at least) if not the whole of the organization. 
3. Whenever you are assigned / picked up something that is not reusable / not applicable to multiple projects, stop. Don't do it. Hand it over to project teams. Let them have some fun as well. 
7. Know what to avoid 
1. Avoid taking decisions. I don't mean to be funny. I seriously mean it. The matters that EA practices "solve" are matters of business, projects, finance etc. There are people whose jobs are on the line to execute a solution e.g. CEO, Project Manager, CFO etc. Your role is advisory. You advise people on "enterprise problems" with multiple suggestions, one recommendation and raw data should they choose to delve into it. But that's where you should draw the line. 
2. Do not get into the technology wars - Java vs. .Net - Agile vs. Waterfall - are simply not for you to fight. Put a framework in place. Get an agreement on the framework from the key stakeholders. Get data - push it through the framework - arrive at a suggestion and hand it over. 
3. Just to prove the point made above, lets take an imaginary scenario: You might have arrived at a suggestion in favor of .Net (in a Java vs .Net decision making progress) and handed it over to the Delivery Manager - and he ultimately might go and choose Java because resources are easily available all of a sudden as some java based software house might have gone bust. It is not a technology based decision. It is an incident in the market that nobody foresaw. Let the Dellivery Manager - whose job is in line to deliver the software product in time and within budget - take the decision that is best for his deliverable. Let him prove to CEO that it is best for the business in long run. Don't be caught standing in the way of business success because it violates some EA finding. 
8. Know when and how to say "No"  
1. Any scope by definition has a tendency to explode if unchecked. However, while the scope of the work of a developer can increase only so much, the scope of EA program can take colossal proportions unless very actively and routinely controlled. 
2. Most of the activities assigned to EA will be multi-year efforts if not more. However, the business appetite to fund a program could start straining as soon as the business hits a bad quarter. It is vitally important to put an iterative approach (half yearly cycle) to achieve a continuous measurable velocity towards any task. 
3. "Out of scope for the current iteration", "Not approved for the current iteration", "Will add that into the to-discuss list for future iteration" are ways of saying no that should not ruffle too many feathers in the corporate world. Practice these phrases as you would practice any other tool in your kitty. 
9. Get down from the "ivory tower" and make friends. 
1. Given that output of EA activities tend to restrictive and prescriptive to the organization, it is likely for EAs to be seen as working in an "ivory tower". This is wrong on two accounts. Firstly it means that it is more difficult to evangelize EA activities and sell the outputs. Secondly it means that the EAs have not got enough information specific to the organization and hence the output is less likely to be tailored for the specific organization.  
2. Get down to the working floor and welcome / invite / allow / reward the bright chaps to contribute in the EA activities. This will make your job easier and win you that many more friends - both factors crucial for success of EA program.  

Work in progress ...

Suggested post read

Tools for EA

If you want to get in touch, you can look me up at Linkedin or Google + .

Software, that you need to create software.

Let me share a secret with you. There is only a handful software, mostly free that are sufficient, enough and really more than enough for managing design and development activities of most of your java based projects. In my career spanning across the globe for more than a decade now, I have seen so many combinations of (mostly non required, pricey, and inept) supporting software, that I am compelled to write down a list of what I consider are must haves (not necessarily free, but worth the price if they are commercial).

Intended audience of this article are enterprises (people working in / for enterprises) which need an end to end holistic approach to manage software solutions. It starts from software that are used to capture the first set of requirements, to software that are used by personnel supporting the product in production. 

Capture requirements
You need a software to put down your requirements in, get others to review, provide feedback, track those feedback, and email around a lot. You need a Microsoft Office or Google docs. Personally I would rather go with Google docs as the collaboration is much much richer. Although one needs to be sensitive to the needs of the business. If you are in a domain which handles sensitive user information i.e. investment bank, Google docs might not be an option for you.
You could do with a wiki (any of the many products that are available in the market e.g. confluence). But I don't think a wiki by itself will be enough. It will need support from other tools.
On the other hand, I have seen product suites like Rational Rose, but frankly I don't think you need that level of sophistication for most of your projects.

Baseline captured requirements
You need a system to put in your requirements once they have been seen and signed off. You could do with any of the version control system i.e. Visual Source Safe. Although I must add VSS has seen bad press e.g. read this. I personally feel very comfortable with Sharepoint. However, I will reiterate, any version control system e.g. SVN  (free) will also work just fine, although there will be some bells and whistles missing.

Create an enforceable architecture
Now just to be very clear, let me explain that I am not suggesting that we create an "enforceable" as in "practical" architecture. I am suggesting that the enterprise invests in any of the tools that allows architects to create visually an architecture that the tool can later run against the source code (that developers will write later) and point out the breaks / deviations from the architecture. Unfortunately, this is not one of those items that you can get cheap or free. The software that allows you to do this are enterprise grade and demand that premium. The two such software that I know of are Structure 101 and Sonargraph.

Use tool to create a basic project structure (standard project structure and not something that someone in the team thinks to be cool)
Use Maven (free) to crate fully functional standards compliant java application skeleton, complete with unit testing, up and running in under 15 minutes. 

You could use Eclipse, IntelliJ or any of the other editors to do this for you, but trust me you are better off sticking to Maven running from command prompt at this stage of project. If Maven creates the basic program, compile and run it from command prompt, it is a standard project (minus any fancy plumbing that any editor might deem necessary) and that means you will have a much smoother time integrating with the host of other tools that I am going to mention later in this article.

Start coding
Import the running skeleton application in Eclipse (free) and start coding. Keep adding unit tests with JUnit (free). Keep a tab on the reporting coverage using Emma (free). Host web based applications in development environment in Jetty (free) and in Tomcat (free) on production environment. Get continuous integration using Jenkins (free) and get all the reports that you need on your source code on Sonar (free).

Test the code (and no I dont mean developers testing their own code and certifying it)
A bunch of testers, testing till wee hours the day before shipping, and ticking off cells in a spreadsheet, is worse kind of nightmare. If you are on the hook for delivering the software (you are a project manager, technical project lead, or any of the other dozen of titles that I keep hearing) and if you find your testing team in this scenario, give up, go home, get a good night's sleep and rewrite your CV. Seriously.

Automate. As much as you can and as early as you can. Have the automated end to end tests running every night and spit out reports every day morning. Take the reports very seriously.

As an enterprise, please invest in something like Quality Center. Please also invest in something that can do performance testing e.g. Load Runner. Selenium (free) is a very good, but underutilized tool. Please invest in buying these tools, evangelizing their adoption, upgrading your resources to make best use of these tools. These are worth the investment.

Move to production
This is an entirely different ball game. We need at the least the following

• A system to deploy applications in production.
• A system to securely manage access for folks working in production. 
• A system for end users to put in helpdesk tickets.
• and a few more ...

I will cover this bit of the puzzle in my followup article on this topic. Till then, happy coding.

This article has been reproduced with slight modifications at http://java.dzone.com/articles/software-you-need-create

If you want to get in touch, you can look me up at Linkedin or Google + .