Technology As Innovator

Apart from motivationally writing for the web, I have been invited to universities as a motivational speaker to talk about the IT industry and IT occupations with IT students.

What question do you think is most frequently asked?

What programming languages and tools are currently used in your company?

It is not a surprising one because the same question has been asked much more frequently on technical forums and newsgroup and has caused so much debates on T-tool vs. U-tool and more heatedly, X-language vs. Y-language.

And my answer is

“It is nice that you are preparing the knowledge and skills that you think your potential employers will seek. However, skills and experience in a particular programming language is not the only technical skill employers seek in candidates. They’re also looking into the foundation technical knowledge, such as but not limited to: Object Orientation, Design skills, Software Methodologies, Data Structures and Algorithms, Database Design, Architecture, Computing Theory, that empower your programming skills. You may do programming with, let’s say, Java relatively well in some situations without the above knowledge, but if you are thrown into a more complex project to build a huge product, the risk is high.

One example. You spend two to four years in college polishing your skills in X language that you predict will (still) be hot in a few years when you graduate. When you do graduate and apply for jobs, if they say “Sorry, X is old. We’re needing Y people”, what will you do? Spend the same amount of time learning Y? No, it’s not the way it should work. Foundation knowledge is the root, languages and tools are leaves. Equip yourself with the foundation, and when technology changes (is IT a slow changing area that does not change every 6 month or so?), you can adapt more easily.

When you have mastered the foundation knowledge, and possessed significant experience in using programming languages, which IDE is not a bug big issue.

Besides, about recruitment, technical skills are not the only evaluation criterion. Think about soft skills and attitude too.”

I was thinking about my profession

The number of Business Analysts and System Analysts required in software companies is not that many compared to developers; in some smaller companies with less formal process definition, some developers take the Analyst role. If the need for Analysts were higher, this question could have been asked: “What modeling languages and tools are currently used in your company?”

The answer is simple: Unified Modeling Language. UML itself has been a well-established language for modeling. More of a reason why it has become so popular is due to the promotion of UML by RUP.

But once again, UML is a language. The case is not much different from that of programming languages. Knowing UML is not enough to perform all tasks Analysts do, Business Process Modeling for instance - and a new standardized set of notations named BPMN (Business Process Modeling Notation) is being proposed.

Underlying UML skills are Modeling skills. Modeling languages are used to present information in a more visual (and structural?) way. You need to know what model or diagram should be used to present what kind of information at what time in what situation to whom.

Model is one kind of information. In order to develop solid Modeling skills, Information Processing skills and Data Analysis skills need to be developed first or in parallel.

With all those skills at hand, you will be able to guess how shapes are categorized and may quickly locate the right notations you need in Modeling tools, no matter if it’s Rational Rose or Visio or Enterprise Architect or so on.

After you have created a good piece of model, you may want to present it to customers or other teams in your project. Presentation skills may help.

Side discussion: Model vs. Diagram

Throughout this article, I have used Models consistently, without mentioning diagrams. The may raise question since “UML diagram” is a very common terminology. The reason is because Analysts produce visualizations which are not diagrams too. Organization charts, map, prototype are just a few to name. ‘Model’ covers all of these, of course including diagrams. Also, one trivia is that the word may remind the fact that information systems actually model the real world.

Conclusion

So to conclude, foundation knowledge is required in any profession. Technology and tools change so quickly, but concepts do not as quickly. Build your internal strength should be the higher priority.

RUP the Star

Rational Unified Process has been one of the most successful iterative processes. It is also one of the firsts to encourage UML as the universal language. With problems of traditional software development methods identified and diagnosed, RUP arises to solve them. From one perspective, RUP is an effort to manage projects by effectively dealing with failure symptoms.

The world is not enough

Looking from the business perspective, one project in a software development company is one business unit. Though bearing specific characteristics, it follows common principles of every business department. It receives from resource management and provides feedback, it employs its own budget and maintains production plan. Something seems missing. RUP serves as a development process; it is contained within the boundary of software development. Organizational aspects, enterprise management and strategy are not looked into.

Moreover, post-deployment system maintenance and support is critical and it has not been described in RUP. Additionally, systems don’t last forever; they need to be replaced. How to decompose and let a system retire also requires a clear process.

Enterprise Unified Process covers these concerns.

EUP extends RUP

Enterprise Unified Process is an extension of RUP. It is created by Scott W. Ambler from IBM Agile Development. From RUP, EUP adds 2 phases and 7 disciplines

Two phases

1. Production phase offers assistance to end users by clarifying queries, resolving production issues by root-cause analysis and applying fixes for dealing with change requests

2. Retirement phase provides guideline on decommission the product

Seven disciplines

1. Enterprise Business Modeling The artifact - enterprise models - distinguishes the relationship between business process, domain process, enterprise activities, functional entities and functional operations. The difference between EUP Enterprise Business Modeling and RUP Business Modeling is that EBM targets goals and vision of the enterprise.

2. Portfolio Management Portfolio and Program management maintain systems inventory snapshots. They build up data for overall efficiency and effectiveness of diversified software projects management, and help scheduling software implementation in a more strategic fashion. Duplication in functionality is eliminated.

3. Enterprise Architecture Enterprise-level Architecture promoted consistency across the entire organization. The impact is on multiple systems for both the present and the future. Enterprise Architects cast their efforts into building a foundation for future enterprise efforts. It is easily seen that the difference between enterprise architecture and application architecture is on scope.

4. Strategic Reuse Reusing software assets ranges from source code, frameworks to strategic approach to similar accounts. The scope being firm-wide makes it very different from reuse within one application.

5. People Management Due to its particular characteristics, HR management and recruitment in the IT industry faces a lot of difficulties. EUP promotes more focus on HR strategies, where organizing, monitoring, coaching and motivating are all standardized to ensure and improve collaboration.

6. Enterprise Administration Network administration, Facilities administration, Information administration and Security administration are universal across all enterprise. In order to generate consistently effective supports and environment to development, all are to be standardized in the enterprise management process.

7. Software Process Improvement Processes need improvement, and even the activities to improve the process are themselves process.

Benefits of EUP

1. Reducing IT costs. Implementing a strategic approach to reuse for the enterprise can significantly reducing your cost of developing software. Just having an enterprise view of architecture will lead to fewer ‘stovepipe’ applications, which are costly to develop and maintain.
2. Improved IT/business alignment. By improving your enterprise business modeling efforts you improve your understanding of the overall business and thereby increase the chances that you will build systems that reflect their true needs. With a portfolio/program management approach to choosing projects you prioritize and then execute projects based on business needs, thereby improving alignment with the business.
3. Improved business planning. Improved enterprise business modeling has the advantage that it provides insight into your overall business needs and vision, insight that can be used by your executives to manage and guide your organization.
4. Higher quality. Reusing software can lead to higher quality, as reusing an already tested component can lead to fewer defects. Leveraging enterprise architectural solutions that have been tested and proved to work ensure that applications built upon those architectures will improve in quality.
5. Improved IT planning and governance. By implementing the portfolio management discipline, you can obtain a better understanding of and control of your software portfolio by recognizing programs, or families of related products. This can lead to better strategic planning and elimination of overlapping requirements in different systems.
6. Improved levels of service. By understanding the ‘big picture’ through enterprise business modeling and enterprise architecture you are able to identify opportunities to take a systems approach to development which looks at the entire picture, not just the IT aspects of a project. For example, a project team should strive to improve the business process as well as (re)build an application for their end users.
7. Greater adaptability. By having an effective approach to enterprise IT issues you will be able to react to changes within your marketplace, such as new legislation or new competition, more effectively because you will have a better understanding of the potential impact of those changes and a consistent way of addressing them.
8. Reducing time to deliver systems. An improved enterprise-level software process will reduce your overall time to deliver systems for several reasons. First, an improved portfolio management approach enables you to identify projects which are more likely to succeed, reducing the change of late and/or cancelled projects. Second, an effective enterprise architecture strategy enables you to work to a common platform, reducing the learning curve of project teams. Third, improved reuse increases your development velocity by enabling you to take advantage of existing assents instead of creating systems from scratch each time.
9. Increased end user productivity. By integrating operations and support into your software lifecycle, you are better able to enhance your end users usage of your system and to respond to their feedback. End user requests for fixes and enhancements are automatically included in the requirements for new releases of systems and ensure that their needs don’t slip through the cracks.
10. Increased developer activity. With an effective approach to enterprise administration, developers can gain the technical resources that they need, such as workstations and network logon IDs easily. This enables them to focus on their jobs, developing working software, and not on trying to get access to resources.
11. Higher return on investment. By leveraging enterprise efforts such as an enterprise approach to architecture and a strategic reuse program, you can reduce costs and speed up development time, realizing a significant increase on ROI.

A glance over the high stance

Initial observation gives the impression that what EUP has to offer are nothing new. Tasks described in Enterprise Business Modeling are named differently and are usually done by Sales, Portfolio Management is crucial to achieve wiki(CMM) level 4, any company has their HR, Properties, IT departments. The problem is that the collaboration is loose and they are standardized very differently from one another. EUP does very well the synthesis job to focus on the omni-picture. It requires very high level management to involve, lead, share the business vision and have it made practical. EUP does have good foundation and reputation of RUP. One good thing is that it is an extension, not a replacement of the still evolving, state-of-the-art RUP.

One important thing to notice, EUP is no magic wand. There has been warning about applying RUP as-a-whole may lead to cumbersome project failure. New EUP disciplines promote even more sophisticated collaboration between desultory departments. Sophistication leads to impediments. The total cost of utilizing EUP may well exceed the sum of costs from single business units.

Reference & Acknowledgement

• Scott W. Ambler, Introduction to the Enterprise Unified Process
• Frans Faase, The answers by Rational Unified Process
• Craig Larman, Philippe Kruchten, Kurt Bittner, How to Fail with Rational Unified Process: Seven Steps to Pain and Suffering
• Sterling Hoffman, Extending the Rational Unified Process: From RUP to EUP
• Gideon Schipper

Problem defined

Managing thousands of artifacts within the requirement phase alone in a project is not an easy task.

Solution

Automation have been provided by these popular software packs

• Documenting Use Cases and documents: Microsoft Word already gives all we need.
• Artifact Repository: Thousands of ways and tools satisfy this purpose. I’d suggest Microsoft SourceSafe and Microsoft SharePoint server.
• Diagram authoring: Rational Rose and Microsoft Visio do better.
• Version control: Many CVS tools are already out there.
• Project Planning: Microsoft Project rocks! Agile’s Product Backlog is also a good tool.

Single Solution

Single solution that addresses most, if not all, issues - a professional Requirement Management Tool that enables the following factors

• Traceability: The efforts spent in wiki(traceability) are greatly reduced. Hence, productivity and team moral are boost.
• Consistency: In a team of nearly twenty people, it might come out that different artifacts owned by different authors vary slightly in styles, indents, numbering. A tool helps to reduce this factor.
• Requirement linking: Reference to other documents, dependencies, extensions are handled in the form of URL links.
• Use Case-to-diagram generation: Many tools allow users to create flow charts from Use Cases

TopTeam Analyst

I recommend this tool: TopTeam Analyst

Demo screenshots

Vendor: technosolutions

TopTeam Analyst is wiki(RUP)-compliant

There are many more requirement management tools, but the reason I am attracted by TopTeam Analyst is that the product is compliant with standards from Rational Unified Process, which I’m am currently working with.