When I learn about RabbitMQ's history, I noticed this statement in one of their articles:
... the reduction of change and maintenance costs through the separation of integration concerns, removal of silo dependency, and freedom from language and platform lock-in ...
From rabbitmq.com 《Launch of RabbitMQ Open Source Enterprise Messaging》, Feb, 2007.
I googled "silo dependency" but I didn't get any useful results. And this word(silo dependency) also sounds different from "Dependency Injection".
Related
According to TOGAF specification, the main domains / division of concerns are:
Business Architecture
Data Architecture
Application Architecture
Technology Architecture
According to the specification, the Enterprise Repository should hold all information.
I have this information:
How it works the company in terms of business model
How it works the application in terms of functional features
How the application is implemented and deployed
How can I map this data according to the TOGAF big picture?
App architecture description --> Architecture Landscape ?
App components description --> Solutions Repository ?
App functional description --> Architecture Capability ?
App deployment info --> ¿?
Business model --> ¿?
Update 08/11/2018
Some questions I have:
Where can I put company info like company structure, people, teams, etc?
Where can I put business info like products and services offered by company, how pricing is calculated? what it means "X thing" for the business?
Where should I put ongoing assessments? and where should I put once it's put in production?
Where should I put a general glossary of terms?
Where should I put development guides? like list of environments, IPs, delivery workflow, jira workflow, etc?
Where should I put service API definitions?
You are trying to mix Solution Architecture and Enterprise Architecture, that's probably why it seems confusing.
TOGAF is about enterprise architecture - big picture stuff, as you correctly pointed out. Information about a concrete app on the other hand is more of a solution architecture concern. Of course, one could argue that you can describe enterprise architecture as detailed as you need, but that's not the point.
Answering your original question, though: it seems like app information (architecture description, components description, functional description) you have should be stored in Architecture Repository as Solution Building Blocks. I'd recommend addressing them as part of Baseline Application Architecture and Baseline Technology Architecture description, during Phase C and Phase D.
Then again, you should first carefully consider wether you really need level of detail this high.
P.S. if you provide a bit more context on what you are trying to achieve, I'd probably be able to give you more specific advice
Update 11/11/2018
Where can I put company info like company structure, people, teams, etc?
It depends. Company structure should be stored in Baseline/Target Business Architecture as part of Organization structure model. Here's a definition from TOGAF:
"Organization structure: document the organization structure, identifying business locations and relating them to organizational units."
It is also one of the inputs - Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 of TOGAF spec).
Where can I put business info like products and services offered by company, how pricing is calculated? what it means "X thing" for the business?
It is also a part of Business Architecture, here's a whole list from TOGAF spec:
Organization structure - identifying business locations and relating them to organizational units
Business goals and objectives - for the enterprise and each organizational unit
Business functions - a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
Business services - the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
Business processes, including measures and deliverables
Business roles, including development and modification of skills requirements
Business data model
Correlation of organization and functions - relate business functions to organizational units in the form of a matrix report
Where should I put ongoing assessments? and where should I put once it's put in production?
There's a standard pattern in TOGAF:
Assess current situation and write it down as Baseline Architecture
Create a vision and write it down as Target Architecture
Work towards Target Architecure and update Baseline Architecture as you go
So, in the end, your baseline should become equal to target and now it's your new baseline for the next ADM cycle.
Where should I put a general glossary of terms?
It's usually done as soon as possible during tailoring TOGAF to your enterprise - Preliminary Phase of the ADM cycle (see Part IV, 36.2.21 of TOGAF spec).
Where should I put development guides? like list of environments, IPs, delivery workflow, jira workflow, etc?
Developments guides, jira workflow and other project management stuff is not usually of a direct concern of TOGAF. It should be definitely be aware of it, enterprise architect might even consult on this matter. Only one thing comes to mind in terms of project management - roadmaps, they are written down and updated as needed during virtually all the phases.
Environments, IPs and other infrastructure information is usually worked on during Phase D, mainly as part of technology architecture models and specifications.
Where should I put service API definitions?
Again, you should carefully consider if you need this level of detail, but it seems appropriate to address it in Phase C (Applications Architecture). One of the steps is defining a model (it's advised by TOGAF to find reference in your industry), which may include API definitions. It's usually enough to address a more abstract Applications Interoperability in terms of the enterprise.
Very important point: TOGAF is just a framework, you can tailor it as you see fit for your current enterprise, just don't forget to document it. You should also remember that it's not just a set of tools, but also a set of expectations, glossary of terms and guidelines, so a new architect wouldn't need to learn everything from the ground up in each new enterprise he works at. As it always goes - you have to find a proper balance point.
As it is included in the license (according to SAP) we would prefer using Solution Manager over other tools, for the entire life-cycle of software development. Or is it highly recommended to use specific tools for the particular processes like Test Management? Any opinions?
in general before answering this question, please be aware that SAP will bring out a new support model and the features and functions available in your SolMan installation will differ according to the support you requested from SAP. If you stick to the Enterprise Support you will (nearly) get every functionality, for Standard Support you well get less and a lot of features will not be included. At the moment, SolMan 7.10 is in Ramp Up Phase and 7.20 will be released in 2011. Due to the fact, that SAP changes the kernel of the Solution Manager Stack, which is apparently CRM from 5.0 to 7.0 you should keep in mind, that any functionality you implement in your current SolMan will lead to high migration efforts.
Apart from this, if you look at the Enterprise version, my experience is that not all features are rather good and suitable. It also depends on the organization you are working in. The SAP tools focus only on SAP, so if you are working in an environment where non-SAP Java has an important part I would look for different tools. If you look into the change management (ChaRM), it is suitable for small landscapes and for big ones only with some effort. Here you should also consider at least to have a look at different technologies and tools. From my point, there are some things like monitoring, job scheduling etc. which are quite good, but for the more general application lifecycle management tools you should at least take other options into account.
I've been evaluating several opensource message queue technologies, such as RabbitMQ, ActiveMQ, OpenAMQ, etc. My question is, what benefits are gained by using a commercial technology such as Tibco EMS, WebSphereMQ, Sonic, etc. instead of something like Active or Rabbit? PHP will be the primary language involved, although Java systems will be interacting as well.
I'd say the benefits are few and far between. You really need to be sure that a commercial system is for you before you invest as there is likely to be no going back.
Some of these things are so esoteric, so prone to vendor lock-in, so damn heavyweight that you'll feel like you have a gorilla on your back, not just a monkey ;)
Those commercial technologies are good, but investment in them can be steep. Both yearly license costs and on-going support costs must be considered when making a decision. As far as vendor lock-in goes, in the commercial world there's only one vendor offering support for a given product. In the open source world, there's typically more than one vendor offering support. Consider ActiveMQ for example. Both Progress Software and SpringSource offer support agreements for ActiveMQ as well as some others.
Also, in the commercial world, you won't ever get to look a the source code yourself. For a product like ActiveMQ, anyone can grab the source code. This is pretty powerful because it means that you can add features, etc. and quite possibly get them added to the product.
ActiveMQ has a great community and is very widely deployed. ActiveMQ provides client APIs for many languages including C/C++, Java, .NET, Perl, PHP, Python, Ruby and more.
There are great communities around projects like RabbitMQ (check out the mailing list for example). Also, if cost is an issue, obviously open source is a win there.
The biggest difference I have found is operational support and management. The commercial vendors usually provide better tools for ops/support staff to resubmit, edit messages etc.
This is often a weakness of open source offerings, which if rectified, should cause some serious lack of sleep for commercial vendors.
I think it's always best to thoroughly examine your requirements before choosing a messaging system:
Not all the commercial vendors will support PHP for example. ActiveMQ and RabbitMQ will.
Not all the messaging systems can support very large Queue sizes - though ActiveMQ does
Not all the messaging systems survive a hard broker stop without loosing messages ActiveMQ will - without you having to use transactions.
And if you are going to use open source - always look at the community - ActiveMQ is the most active community of any open source message vendor - and it's also Apache - which means diversity and no reliance on any single developer or vendor for delivery.
If you use commercial products it comes with everything(just we have
to use) but all the open source products will have basic features but
still we can implement commercial product features(involves lot of
development)
Documentation is not the favorite area of a developer but an important area to fulfill if you want to have standards in the organization. We are trying to put together a new Configuratio Mgmt Plan to setup Change Controls, Backups strategies and other fun things, like the process from development, staging to production.
I will like to have your opinions on good examples or probably a good start for CMP process.
If you would like some list of the item in software configuration management plant, this links provide an example: http://www.scmwise.com/software-configuration-management-plan.html
However, please notes that the content of SCM plan is highly dependent on your company standard and the process during software development itself.
I usually refer cmcrossroads.com for such information. The site is not organized well but has lots of info. Another very useful resource is nasa.gov (I know).
Rather than me listing out the index of a CM plan, I would recommend you to check this link out: http://www.nasa.gov/centers/ivv/pdf/170879main_T2401.pdf
Some quick pointers for setting up CM process:
You absolutely need the
management's/corporation's backing.
Without them pushing, no one will
adhere to the process.
SCM is like police/postal service. No one remembers them until something goes wrong. In your case, it is a good sign if no one talks (complains) about your implemented SCM process.
Open source SCM systems are at par with the other kind. Depending on the intensity of your project, you may have to do several POCs to determine which system suits your needs.
This is a vast topic; I would recommend Alexis Leon's book if you are stuck.
Software development related all kind of documents are available as part of Rational Unified Process[RUP]. You can find those at:
Configuration management Plans
RUP templates
RUP templates
Assume your .NET-based development team is already using the following set of tools in its processes:
Subversion / TortoiseSVN / VisualSVN (source control)
NUnit (unit testing)
An open source Wiki
A proprietary bug-tracking system that is paid for
You are happy with Subversion and NUnit, but dislike the Wiki and bug-tracking system. You also would like to add some lightweight project-management software (like Fogbugz/Trac) - it does not have to be free, but obviously cheaper is better.
Can you make a compelling argument for adopting VSTS, either to add missing features and replace disliked software or to handle everything (including the source control)? Is the integration of all these features greater than the sum of the parts, or would it simply be better to acquire and replace the parts that you either do not like or do not have?
I remember looking into VSTS a few years ago and thought it was terribly expensive and not really better than many of the free options, but I assume Microsoft has continued to work on it?
VSTS is great, if you do everything in it. Unfortunately the price has not become better over the years. :( The CAL's are still ludicrously expensive. The only improvement is that if a person uses only the work item system, and works only with his/her own work items (no peeking at other person's work items!) then there is no need for a CAL. This makes it a bit easier to use it as an external bugreport system. Still it leaves a lot to be desired in this area.
There is one way to alleviate the cost - become Microsoft Certified Partner. If you are a simple partner, you get 5 VS/TFS licenses for free; if you are a Gold Certifiend Partner, you get 25 (if memory fails me not). That should be enough for most companies. But getting the Gold status might be tricky, depending on what you do.
If you only dislike those two parts, then perhaps it's better just to find a replacement for them instead for everything? There are many wiki systems out there, some should be to your liking. The same goes for bugtracking too.
We are extremely happy with not only the tools, but the integration that Team Foundation Server, and the various Team Editions have given us. We previously used Borland's StarTeam for source control and issue tracking with a 3rd party wiki, the name of which escapes me at the moment.
It came time for us to extend our licensing and support agreement with Borland, only to learn that the cost of adding users to our license and upgrading the product would cost us as much (a little more, actually) than biting the bullet and making the switch. One thing to consider is that you would normally pay for the development tools to begin with, so the cost is partially absorbed by our budget.
We also did not feel the need for getting Team Suite for every person. You might want to consider it for the developers, but other disciplines don't really have a benefit in using all of the tools in most companies.
We were able to get the appropriate team editions for twelve people, enough CALs for 50 users (for Team Explorer, Teamprise, Team Project Portals, Team Web Access), Teamprise for the five Mac Users that we have, and the Team Foundation Server software itself for under six figures. Considering that includes the developer tools that we normally would be buying, it was a good deal.
The upfront cost on new licensing also covered two years, so we could split the budget between the 2008 and 2009 fiscal years. The very important thing is to make sure not to let the licenses lapse, as the renewals on licenses cost a fraction of the initial cost and also include version upgrades.
As to the features, we are in the process of rolling out. About half of our department completed training, and I have already started migrating projects over. The development team absolutely loves the features and tight integration with their workflow. Version control is a snap, and work items (and their related reporting artifacts) are extensible to the nth degree. The fact that TFS relies heavily on bringing sanity to workflow management helps to tie in all of the processes to a level that you just can not get with multiple vendors.
My absolute favorite thing, though, is the extensibility model. Using the Team Foundation Server API, you can easily write check-in policies, write tools to interface with the system, develop plug-ins, and more. We are already seeing gains in productivity and the quality of our products through a minimal implementation.
Still on the horizon, though, is integrating Team Build. I have yet to set up a build project, but it seems to be seamless and painless. Time will tell... :-)
Edit - I forgot to mention that our migration to TFS includes licensing for the Test Load Agent. The load testing functionality within Team Test is one of, if not the absolute best that I have seen.
Where I'm at, we've settled on the following:
SVN for source control
Redmine for bug-tracking and wiki
NUnit for unit testing
CruiseControl.NET for our build server
Redmine is an open source Ruby on Rails application that supports multiple projects much better than Trac and seems to be much easier to administer. It's definitely worth checking out.
VSTS seems to be way too much money compared to other products. As an additional benefit, you also get the souce with open source solutions, which allows you to modify things to fit your need if the capability isn't there yet.
I'd stick with SVN and use trac or bugzilla or fogbugz. You could also do a trial of team server. In my opinion it is not worth the money. MS had their chance with version control and they screwed it up a long time ago. Too late to the party if you ask me and frankly I am not impressed with how they try to control all your development experience in the IDE with "integration" to the source control. I prefer the perforce/SVN and separate defect tracking solution.
With all that said, you probably can't go wrong with any of the following:
bugzilla or trac or fogbugz AND SVN
MS team thingamabob