* Note:- This is a continuous improvement topic and is being upgraded at present.
We have tried explaining on:-
1. What are the problem you face, when you implement highly critical business solutions with your software application?
2. How do you manage and improve qualities while delivering solutions much ahead of actual time lines.
3. How can you stop the project from failing?
4. Architectural principles and pattern's which can play an important role.
5. Delivery methodologies and stake holder management to keep the confusion at the lowest.
6. Mapping your team mates so that they should be doing what they are best fit for.
7. The theory of team formation whom and when to hire?
8. How to communicate to your stake holder? Is it Just
Zacmen or something else like one below?
Some of the the problem that one face's and The easiest way to stop the project from failing because of may be one of the below issues.
1. Analysis was wrong.
2. You where trying to implement your halfed cooked artifacts because you never took half of the view points from important stake holders in to consideration.
3. Was the usability being taken care of as an important view point and its artifacts as the outcome?
4.Confusion, job threat and other managerial false promises forced you to start the development on a premature artifacts leading to Jugad [quick and dirty fixes here and there], while it ran for some time and then it broke as if it was meant to be broken.
5. While making it simple and analyzing all, you delayed so much that you ignored time and funding consideration.
6. The people whom you hired where not to be called engineers but one of the below:-
An opportunist looking to sell some half cooked knowledge,
More interested to be a manager.
Struggling to Jump and be comfortable on the branches of big corporate tree as like monkeys.
7. Was the engineering team mature enough to positively action on criticism and suggestion?
8. How did you manged the negative energy in the team?
Negative energy? is it a normal case? yes it is:-
The amount of positive work that you do results in equivalent amount of negative energy being splashed
around. This is true for any matter or by product of matter.
This may be considered as the kind of balancing energy according to the theory of relativity,
Matters and Antimatter's.
Remember the vibrations in and around the group which creates such beautiful by products
consumes energy and energy and matter are related by the formula e= mc square.
This is not just science but the law of nature.
When you utilize matters or energy in any form you will have to do something with the anti matters and negative energies too. I may have to dive deep relating the theory of TIME and Black Holes, Einsteins theory of relativity Stephan Hawkins (Who created the universe?), Newtons third law, The Power of Karma Yoga, Theory of creation and displacement of material particle.
Are this all not a form of energy in the form that human may or may not understand.
Most probably you will be facing one of the pain penned below as an outcome of above fact as an It Guy.
- You reviewed and spoke about lot of pattern and practices.
- You applied many of them in your IT products.
- You created test harness and kept changing them.
- You created solutions and keep improving them, While you fix one you broke others.
- Your code wept when on heavy load and huge data.
- You had a big QA setup just encase you break something !!!
Question is how to manage this all and still meet client expectations?
The below practices suggest how, where and when to manage a successful delivery and architecture in less time and less future operation's cost.
What to think when you are proposing the Web or Windows solution at system level?
Not an exhausted list but some of the checklist should be..
1. What is the business problem that its going to serve for?
2. How Many users to serve for?
3. Will we have the control to their environment?
4. How do we ship our changes to the client?
5. What will be our error handling and reporting capabilities?
6. How easily can we change our code without affecting other area?
7. How can we care about scalability?
8. How can we Extend our architecture?
9. How do we segregate our DATA, DATA Transformations, Disconnected and Connected Data stores, Harmonization, Extensions and metamorphosis before we deliver data in the fast efficient, required manner to our Business, Domain and UI workflow to serve or act on one of the actions [In or Out] to the system, time, application and Human based actors.?
10. How do we manage Generalization, specification, aggregation, association, composition and decomposition based needs of our Target architecture as an Universe as well as multiple systems and their components as their sub systems.
11. How do we Visualize the data delivery, Objects and data transfers between object's inside and beyond system boundaries.
12. Do we really need to break the interfaces as in thousands or keep the common interface for all sorts of communication.
13. Does the common interface handles normalization?
14. Is the common interface is their to serve Large Objects to make the client work in disconnected fashion? Or has a chatty interface to make the data transfer in chunk and keep connected?
15. Does the in memory transformations has frequent call's to multiple systems out side the sub systems or out side the domain boundaries?
16. Are their federations of the copy of the system which will interact among each other to make themselves scalable.
Choosing the technology?
1. What will be the Cost/ Benefit ratio?
3. Is Development and Deployment infrastructure supported?
4. Open standards [Best for web] for an intranet [organization standards on which the enterprise system runs, users are trained and have less cost to implement.]
5. Does it fits in to enterprise technology, data, business and application stack well?
6. The level of your technical workforce that you have and easily available in market and in sustainable range?
7. How easy will it be to implement when you do the GAP analysis?
1. One of the biggest challenge for the system integrator, solution and technical architect's is infrastructure.
2. Even if they know and development team does not know how the application will be installed hosted in different environment, application development may miss the important point [capability][Maturity]
3. Intranet based enterprise have different infrastructure constraints which may change from enterprise to enterprise and are mostly based on their capabilities derived by the factors like robustness, technical work force, Maturity models that they are at CMMI ?, enterprise architectural practices and framework applied.
Rules and Enterprise governance activities as well as IT services standard adoptions such as ITIL.
Serving The Business and The Actors
Knowing the different actors is an important step towards building an application.
- Actor may be a system based or Live actor.
- System based actor's are services which may interact with different components.
- A component which may get initiate by an activity from another component in [Inside or outside of the domain] or even from outside the universe.
- The solution that you build is storied around these actors.
- That's how one frame the view's from these actors and bespoke creators of these actors[Super actors].
- Extract the viewpoints and further create their artifacts around these base actors or derived, evolved, metamorphosed, extended need based system & non system based relatives.
- Once your stories are created you start binding them up with your solutions [Application, components, derived system based actors their activities and associations, security modeling[Authorization & Authentication]]
- Actors may be main or side actors but unless they are not being powered and instinctive to perform their role in a winning way the film is a flop.
GAP Analysis which is the most important way to manage your entities attributes and models.
Every enterprise have one important issue to deal with [Duplicate applications for same problem]
1. There is no centralize data dictionary and a Gap analysis tool where technologist can easily find the data origination source, Master data and the transformation through different systems.
The DATA flow, Transformations, Managing the inlets , outlets, tank's and sync's.
The importance of Open Close Principle, Test Extensions and separation of concerns.
The existing patterns which may be helpful to you.
The Simple pattern described below is a solution level pattern which allows easy extension of your applications at specific inlets and outlets as like a system of multiple pipelines.
If you are asked to know all the scenarios at the begin of the development? most of the time its not possible.
This does mean that your team will make their handle dirty in tight deadline.
How to Mange the solution and application level architecture that you can easily manage some core areas, despite having scope of improvement at lower level.
1. Data, Data transformation, Data Flow
3. Business Scenarios
The Simple Pattern:
Infrastructure and Development Environment Readiness and leval?
References Comments & Scenarios:-
To understand what is this all about?
Read the below link.
This is one of the awesome post you will ever find..